perm filename MSG.MSG[X3,LSP]30 blob
sn#859385 filedate 1988-07-07 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00183 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00025 00002 ∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
C00027 00003 ∂09-Oct-86 1136 RPG Greetings
C00028 00004 ∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
C00030 00005 ∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
C00037 00006 ∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
C00039 00007 ∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
C00041 00008 ∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
C00043 00009 ∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
C00046 00010 ∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
C00048 00011 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
C00049 00012 ∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
C00052 00013 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
C00059 00014 ∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
C00061 00015 ∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
C00062 00016 ∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
C00064 00017 ∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
C00065 00018 ∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
C00069 00019 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
C00071 00020 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
C00078 00021 ∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
C00080 00022 ∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
C00082 00023 ∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
C00084 00024 ∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
C00086 00025 ∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
C00088 00026 ∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
C00090 00027 ∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
C00093 00028 ∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
C00099 00029 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
C00118 00030 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
C00123 00031 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
C00129 00032 ∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
C00135 00033 ∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
C00139 00034 ∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
C00166 00035 ∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
C00173 00036 ∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
C00176 00037 ∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
C00178 00038 ∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
C00186 00039 ∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
C00197 00040 ∂10-Feb-87 0246 RPG Registration
C00198 00041 ∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
C00209 00042 ∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
C00216 00043 ∂27-Feb-87 1453 RPG X3 registration list 2/27/87
C00221 00044 ∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
C00223 00045 ∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
C00225 00046 ∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
C00229 00047 ∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
C00231 00048 ∂12-Mar-87 2210 RPG Final Attendee List
C00238 00049 ∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
C00240 00050 ∂13-Mar-87 0852 RPG Writer
C00241 00051 ∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
C00256 00052 ∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
C00277 00053 ∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
C00279 00054 ∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
C00280 00055 ∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
C00284 00056 ∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
C00288 00057 ∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
C00291 00058 ∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
C00295 00059 ∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
C00297 00060 ∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
C00303 00061 ∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
C00345 00062 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
C00395 00063 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
C00451 00064 ∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
C00458 00065 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
C00504 00066 ∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
C00553 00067 ∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
C00603 00068 ∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
C00655 00069 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
C00710 00070 ∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
C00763 00071 ∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
C00765 00072 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
C00770 00073 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00776 00074 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
C00781 00075 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
C00788 00076 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
C00793 00077 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
C00799 00078 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
C00803 00079 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00809 00080 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
C00813 00081 ∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
C00818 00082 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
C00822 00083 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
C00828 00084 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
C00836 00085 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
C00843 00086 ∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
C00855 00087 ∂16-Jun-87 2337 Masinter.pa@Xerox.COM
C00867 00088 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
C00881 00089 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
C00905 00090 ∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
C00909 00091 ∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C00916 00092 ∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
C00922 00093 ∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C00925 00094 ∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C00929 00095 ∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
C00933 00096 ∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
C00941 00097 ∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C00944 00098 ∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
C00946 00099 ∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
C00951 00100 ∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C00954 00101 ∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C00958 00102 ∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
C00962 00103 ∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C00966 00104 ∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
C00968 00105 ∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C00970 00106 ∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
C00972 00107 ∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C00974 00108 ∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
C00977 00109 ∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C00979 00110 ∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
C00982 00111 ∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
C00986 00112 ∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
C00988 00113 ∂23-Jun-87 1104 RPG Meeting Room at MIT
C00991 00114 ∂25-Jun-87 2342 RPG Meeting Room
C00992 00115 ∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
C00994 00116 ∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
C00995 00117 ∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
C00997 00118 ∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
C01024 00119 ∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
C01049 00120 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
C01054 00121 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
C01079 00122 ∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
C01081 00123 ∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
C01084 00124 ∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
C01086 00125 ∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
C01092 00126 ∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
C01107 00127 ∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
C01121 00128 ∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
C01129 00129 ∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP 20 Oct 87 16:36:09 PDT
C01132 00130 ∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP 22 Oct 87 08:39:11 PDT
C01134 00131 ∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
C01137 00132 ∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
C01139 00133 ∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
C01156 00134 ∂11-Nov-87 1800 X3J13-mailer Final reservations
C01162 00135 ∂12-Nov-87 1335 X3J13-mailer next meeting
C01165 00136 ∂29-Nov-87 1424 X3J13-mailer subcommittees
C01169 00137 ∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
C01181 00138 ∂14-Dec-87 1055 X3J13-mailer March meeting
C01193 00139 ∂11-Jan-88 1056 X3J13-mailer mailings
C01195 00140 ∂11-Jan-88 1249 X3J13-mailer mailings
C01201 00141 ∂26-Jan-88 1107 X3J13-mailer voting
C01206 00142 ∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
C01208 00143 ∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
C01212 00144 ∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
C01220 00145 ∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
C01228 00146 ∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
C01235 00147 ∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C01240 00148 ∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
C01245 00149 ∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
C01250 00150 ∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
C01255 00151 ∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C01260 00152 ∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
C01275 00153 ∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C01281 00154 ∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
C01287 00155 ∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
C01293 00156 ∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01299 00157 ∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
C01308 00158 ∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
C01315 00159 ∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C01324 00160 ∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01332 00161 ∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
C01339 00162 ∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C01353 00163 ∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
C01382 00164 ∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
C01391 00165 ∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
C01406 00166 ∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
C01412 00167 ∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01432 00168 ∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
C01445 00169 ∂14-Feb-88 1408 X3J13-mailer
C01452 00170 ∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
C01461 00171 ∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
C01481 00172 ∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
C01483 00173 ∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
C01485 00174 ∂23-Feb-88 1308 X3J13-mailer Re: voting
C01487 00175 ∂23-Feb-88 1541 X3J13-mailer voting
C01499 00176 ∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
C01502 00177 ∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
C01505 00178 ∂24-Feb-88 1140 X3J13-mailer voting at X3J13
C01508 00179 ∂28-Feb-88 1147 X3J13-mailer ISO meeting news
C01510 00180 ∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
C01514 00181 ∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
C01516 00182 ∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
C01518 00183 ∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
C01524 ENDMK
C⊗;
∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 86 06:15:52 PDT
Date: Thu, 9 Oct 86 09:14:26 edt
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8610091314.AA20136@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp-request@su-ai.ARPA, mathis@b.isi.edu, rpg@sail.stanford.edu,
x3j13@sail.stanford.edu
Subject: ANSI X3J13 committee
Cc: jjohnson@mitre.ARPA
Greetings to all recipients of this message. I would appreciate your including
me on any correspondence concerning the standardization of Common Lisp within
ANSI and any other countries contributions to this ISO effort since I
am MITRE's representative on the X3J13 committee.
Sincerely,
Jerry Johnson
MITRE Corporation
AI Center
Mail Stop W418
1820 Dolley Madison Blvd
McLean, VA 22102
703-883-7173
∂09-Oct-86 1136 RPG Greetings
To: x3j13@SAIL.STANFORD.EDU
I am sending this message to reassure you that the X3J13
mailing list exists. The net address is:
x3j13@sail.stanford.edu
and the request address is
x3j13-request@sail.stanford.edu
-rpg-
∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 86 15:47:04 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 6231; Fri 10-Oct-86 18:44:00 EDT
Date: Fri, 10 Oct 86 18:44 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Meeting conflict
To: x3j13@SAIL.STANFORD.EDU
cc: Hewitt@XX.LCS.MIT.EDU
Message-ID: <861010184419.6.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Folks,
I will be able to attend the next meeting on December 10 and 11 but not Dec.
12 because I have two scheduling conflicts on the 12th (it's my birthday and I
have to be present at another conflicting meeting on Friday the 12th).
--Carl
∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 06:53:28 PST
Date: 27 Oct 1986 06:30-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 Meeting Dallas Dec 10-12
From: MATHIS@ADA20.ISI.EDU
To: X3J13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]27-Oct-86 06:30:46.MATHIS>
The second meeting of X3J13 will be held from 1pm, Wednesday,
December 10, 1986, until noon, Friday, December 12, 1986, at the
Sheraton Park Central in Dallas, Texas. Arrangements have been
made by Ellen Waldrum of Texas Instruments.
Many aspects of these early meetings are attempts to determine
the best things for this committee. There was some feeling that
this three day format was better than a two day format from both
travel and work perspectives. Having the meeting in a hotel makes
somethings easier, but it also makes the meal service more
expensive. TI graciously offered to help offset some of these
costs, but I thought that was the wrong precedent to be setting.
At the first meeting, it seemed that most people brought lunches
back to the meeting room so they could keep discussing various
issues; that is why we arranged a lunch for Thursday. At every
other TI sponsored meeting I have ever attended (once before)
there was an informal dinner (everyone ordering from the menu and
paying their own) at the Trail Dust (which is good and very
informal). We could make these arrangements for Wednesday night.
All of these food arrangements are optional.
Other aspects of the meeting (agenda, discussion papers, etc.)
will be covered in subsequent messages. -- Bob Mathis
The following is from Ellen Waldrum:
X3J13 December Meeting Registration Form; mail to:
Beverly Williams
Texas Instruments
P.O. Box 655474
MS 3651
Dallas, Texas 75265
A block of rooms is available at the Sheraton Park Central. The
rate will be $60 a night (plus tax). Please check the
appropriate dates and supply a credit card number if you wish to
have the room guaranteed. Coffee, juice, breakfast rolls, and
fruit will be available for the morning sessions and coffee and
soft drinks will be available for the afternoon sessions. Lunch
has been arranged for the Dec. 11 meeting. The cost per person
for this food service is $25. Please include a check for this
amount with the registration form if you wish to partake. Delta
Airlines has agreed to give participants a 40% discount.
Unfortunately, the reference number needed for reservations is
not available yet. It will be posted to the X3J13 mailing list
as soon as it is known. There has been some interest expressed
in having a group dinner at the Trail Dust the evening of Dec.
10 with an extra cost. If enough people want to participate,
reservations will be made. If you are interested, please note
this in the appropriate space below. If you have questions about
room or airline reservations, please call Beverly at
214-997-2108. Questions of a more general nature about the
arrangements should be directed to Ellen Waldrum at 214-995-6716
or net mail address Waldrum%TI-CSL@CSNET-RELAY.
Name:
------------------------------------------------------
Institution:
----------------------------------------------
Street Address:
--------------------------------------------
City: State: Phone:
----------------- ---- ----------------
Reservations: Dec. 9: Dec. 10: Dec. 11:
----- ----- -----
Credit Card: AE MC Visa Number:
--- --- --- ---------------------
Food Service: Yes No
--- ---
(Please make check payable to Texas Instruments)
Dinner at Trail Dust: Yes No
---- ----
The room rate is only guaranteed for reservations made before
November 17 so please mail this form as soon as possible.
∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 07:23:18 PST
Date: 5 Nov 1986 07:14-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 second mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Nov-86 07:14:06.MATHIS>
I just sent out in US mail the second x3j13 mailing. In it I
said you should also have seen it on this electronic address.
Due to a computer problem (which you don't want to hearabout) I
am unable to send you the total information electronically; I am
however still able to communicate somewhat on the net.
If you have anything you want sent out before the next meeting I
should have it by November 14. In this case hardcopy that I
could photocopy would be helpful.
Remember to send in your hotel reservations for the Dallas
meeting.
-- Bob
∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:55 PST
Received: from ti-csl by csnet-relay.csnet id af01601; 13 Nov 86 8:10 EST
Received: from Puff (puff.ARPA) by tilde id AA04521; Wed, 12 Nov 86 16:05:10 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: Delta reference number
Date: 12-Nov-86 15:59:39
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741205578@Puff>
I had just sent the previous message when my phone rang.
Of course it was Beverly calling with the number I had
just told you was not available yet. To take advantage
of the Delta Airlines discount, you must make your
reservations through the Delta convention desk. The
phone number is 800-241-6760 and the reference file
number is B0238. We are listed with them as the
Computer Science Show. This discount is only good for
reservations made at least seven days in advance and
there are no penalties for cancellation. If you have
any questions or problems, please call Beverly or me
or send mail (Waldrum%ti-csl@csnet-relay).
-- Ellen
∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:26 PST
Received: from ti-csl by csnet-relay.csnet id ae01601; 13 Nov 86 8:08 EST
Received: from Puff (puff.ARPA) by tilde id AA03964; Wed, 12 Nov 86 15:49:14 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: December Meeting
Date: 12-Nov-86 15:43:45
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741204624@Puff>
If you are not able to mail your form in time to meet the
November 17 deadline and wish to make a reservation, you
should call Beverly Johnson at 214-997-2108 and give her
the pertinent information. If you do call Beverly, please
send the form anyway as verification.
The Delta airlines reference number is still not available.
All of the paperwork is done but Delta has not provided this
bit of pertinent information yet. It will be posted as soon
as we get it and Beverly will be calling those of you who have
already inquired.
-- Ellen
∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:02:34 PST
Received: from ti-csl by csnet-relay.csnet id ad04601; 25 Nov 86 15:42 EST
Received: from Puff (puff.ARPA) by tilde id AA23037; Tue, 25 Nov 86 13:32:15 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Reservation confirmation
Date: 25-Nov-86 13:28:28
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742319706@Puff>
I have received reservation forms from the following
people:
Beckerle, Michael Hadden, George
Boelk, Mary Haflich, Steve
Brown, Gary Hewitt, Carl
Cugini, John Kiczales, Gregor
Daniels, Andrew Loeffler, David
Dussud, Patrick Margolin, Barry
Dabrowski, Christopher Perdue, Crispin
Ennis, Susan Rand, Douglas
Fahlman, Scott Rosenking, Jeffrey
Foderaro, John Wegman, Mark
Gabriel, Richard Wieland, Alexis
The following people have made reservations by phone
but the form has not yet arrived:
Beman, Richard Moon, David
Clinger, Will Vandeusen, Mary
Goldstein, Brad Weinreb, Dan
Masinter, Larry White, Jon
If your name is not in one of these lists and you
think it should be, please let me know ASAP.
Thanks,
Ellen
Waldrum%ti-csl@csnet-relay
214-995-6716
P.S. I will have receipts for the checks available
at the meeting.
∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Nov 86 13:55:32 PST
Received: from ti-csl by csnet-relay.csnet id bz12469; 27 Nov 86 16:45 EST
Received: from Puff (puff.ARPA) by tilde id AA09163; Wed, 26 Nov 86 15:41:43 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Additional reservations
Date: 26-Nov-86 15:36:49
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742413804@Puff>
When I send the original list of reservations, a
few names were inadvertently omitted. The following
people have also made phone reservations, but the
paperwork has not yet arrived:
Antonisse, James
Bobrow, Danny
Chaihalloux, Jerome
Giansiracusa, Bob
Mathis, Bob
Ohlander, Ron
Pitman, Kent
Steele, Guy
I have received a reservation form from Mary Van Deusen.
-- Ellen
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:15 PST
Date: 5 Dec 1986 11:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting in Dallas
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:46:24.MATHIS>
I have just sent out some last minute documents. I hope that you
have all made your arrangements. Two messages follow: first is
cover letter on that mailing; second is draft agenda outline. If
you have any questions or comments, please be in touch. -- Bob
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:02 PST
Date: 5 Dec 1986 12:00-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting draft agenda outline
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:00:32.MATHIS>
agenda header -- 1
1 Call to Order, December 10, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-???)
5 Report on International Activities (Doc: 86-017)
6 Other Liaison Reports
7 Review of Goals and Objectives (Doc: 86-005)
8 Brief Overview of Technical Topics on Agenda
9 Recess, 5:00pm
agenda header -- 2
10 Call to Order, December 11, 9:00am
11 Function/Value Cells (Doc: 86-010)
12 Relationship of Common Lisp and Scheme
13 European approach to defining via levels
14 LUNCH Second Day, 12:00-1:00pm
15 Error Systems (Doc: 86-011, 86-012, 86-013, 86-014)
16 Update on object system discussions (Doc: 86-018)
17 Handling technical discussions
18 Recess, 5:00pm
agenda header -- 3
19 Call to Order, December 12, 9:00am
20 Summary of Technical Issues and Discussions
21 Planning Relative to Other Technical Issues
22 Call for Officer Candidates
23 Future Meeting Schedule (Doc: SD-04)
24 Review of Action Item Assignments
25 Adjournment, 12:00noon
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:25 PST
Date: 5 Dec 1986 11:56-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: third mailing cover letter
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:56:16.MATHIS>
Doc. No.: X3J13/86-015
Date: December 1, 1986
Project: X3J13 Common Lisp
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
Ph: (703)425-5923
Mathis
X3J13 Members, alternates, observers, and potential participants:
This is a last minute reminder of the next meeting in Dallas on
December 10-12, 1986. If you have yet to make your reservations,
call Beverly at TI at (214)997-2108 or for general information,
Ellen Waldrum at (214)995-6716.
1. The minutes of first meeting have been delayed due to an
unforeseen sequence of unforeseeable circumstances which should
have been predictable. They are promised for the meeting in
Dallas.
2. Enclosed with this letter are the preliminary papers on
function cells and error systems.
3. At the ISO/TC97/SC22 Advisory Group meeting in Vienna, it was
decided to move ahead for a new work item on Lisp with a convenor
coming from France and a project editor coming from the United
States. This will be an item for discussion at the Dallas
meeting.
4. I had the opportunity to meet with Cathie Kachurik of the X3
Secretariat and Gary Robinson of DEC (who also happens to be
quite active in X3 and ISO/TC97) about the use of the Steele book
as a basis for the eventual standard. This issue was the basis
for some motions at the last meeting, which at the current time
are out of order. In our general discussions of goals and
objectives for the X3J13 committee, we need to discuss the actual
form we envision for the eventual standard and how closely it may
be related to the Steele book or to other manuals which have been
developed by other companies.
5. Remember that after this second meeting, we will have to
propose to X3 a set of officer candidates for X3J13. If anybody
wants to serve they should be prepared to make it known at this
meeting.
6. There will be a detailed proposed agenda at the start of the
meeting, but for your planning: Wednesday afternoon will include
brief overviews of the various topics on the agenda and an
extended discussion of goals and objectives for X3J13; Thursday
morning will begin with the function/value cell discussion;
Thursday afternoon will begin with the error system discussion;
and Friday morning will be devoted to finishing up remaining
topics.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Attachments:
X3J13/86-010 "Issues of Separation in Function Cells and Value
Cells" by Gabriel and Pitman with others
X3J13/86-011 "Exceptional Situations in Lisp" by Pitman
X3J13/86-012 "Error Proposal #8 as of 8/4/86" by Pitman
X3J13/86-013 "Error Proposal #8 implementation suggestion as
of 8/4/86" by Pitman
X3J13/86-014 "Error Proposal Feedback up to 11/19/86"
∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 18:25:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Dec 86 21:25:36-EST
Date: Fri, 5 Dec 1986 21:25 EST
Message-ID: <FAHLMAN.12260501376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SU-AI.ARPA
Subject: Logisitcs for Dallas meeting
I have a couple of questions about local arrangements for the Dallas
meeting. Could someone from TI send the following info to this mailing
list. (My apologies if this info was in some earlier mailing -- I can't
seem to find it if so. Maybe it was on the reservation form, which I
mailed in and didn't copy.)
1. Mailing address and phone number of the Sheraton Park Central.
2. How to get there from DFW airport. Approximate price and time
required for a taxi. Is there any cheaper way to make the trip, such as
a hotel limo? A lot of us will probably be arriving 10 - noon on
Wednesday, and will be heading back to the airport after adjornment on
Friday.
Thanks,
Scott
∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:00:46 PST
Date: Mon, 8 Dec 86 11:50:17 est
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8612081650.AA17339@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@ADA20.ISI.EDU, x3j13@SU-AI.ARPA
Subject: Re: meeting in Dallas
Bob
My new mailing address is
Jerry Johnson
MITRE Corp
Mail Stop W418
1820 Dolley Madison Blvd
McLean VA 22102
Jerry
∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 86 03:57:48 PST
Received: from ti-csl by csnet-relay.csnet id ad02710; 10 Dec 86 6:34 EST
Received: from Puff (puff.ARPA) by tilde id AA00397; Mon, 8 Dec 86 17:37:01 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Logistics for Dallas Meeting
Date: 8-Dec-86 16:50:13
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2743455011@Puff>
Thanks for the suggestion, Scott.
The mailing address of the hotel is
Sheraton Park Central
12720 Merit Drive
Dallas, Texas 75251
and the phone number is 214-385-3000.
Taxi fare from DFW to the hotel should be
approximately $20. There is also a shuttle
service called The Link that charges $9.
The approximate travel time is 30 minutes.
-- Ellen
∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 86 18:55:23 PST
Date: 12 Dec 1986 18:25-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]12-Dec-86 18:25:14.MATHIS>
Thanks to everyone. I think we had a very productive meeting.
We have a lot of work to do in preparation for the March 16-18,
1987, meeting in Palo Alto. Let's keep the communication going.
Watch this space and help fill it. -- Bob Mathis
∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
To: x3j13@SAIL.STANFORD.EDU
Here they are:
rpg
#msg.msg[jnk,jmc]
hst
"uwmcsd1!marque!maxiv"@UNIX.MACC.WISC.EDU
coffee@AEROSPACE.ARPA
cugini@ICST-ECF
dabrowski@ICST-ECF
"J.Dalton%uk.ac.edinburgh"@CS.UCL.AC.UK
ffitch@RAND-UNIX
padget@RAND-UNIX
NGALL@BBNG.ARPA
"barmar%bco"@HI-MULTICS.ARPA
hadden@HI-MULTICS.ARPA
hemphill@NRL-AIC.ARPA
"uwmcsd1!marque!gregj"@RSCH.WISC.EDU
"fkunze%franz.uucp"@UCBVAX.Berkeley.EDU
"jkf%franz.uucp"@UCBVAX.Berkeley.EDU
"smh%franz.uucp"@UCBVAX.Berkeley.EDU
Baggins@IBM.COM
Brandon@IBM.COM
"marick%mycroft"@GSWD-VMS.ARPA
dougr@MIT-EDDIE.ARPA
"primerd!barryn"@MIT-EDDIE.ARPA
"mcvax!inria!chaillou"@seismo.CSS.GOV
"mcvax!inria!crcge1!neidl"@seismo.CSS.GOV
peck@SPAM.ISTC.SRI.COM
scherlis@VAX.DARPA.MIL
squires@VAX.DARPA.MIL
gls@ZARATHUSTRA.THINK.COM
Wegman@IBM.COM
antonisse@MITRE.ARPA
jjohnson@MITRE.ARPA
Wieland@MITRE.ARPA
Yonke@USC-ECL.ARPA
Ohlander@ISI.EDU
balzer@A.ISI.EDU
Mathis@A.ISI.EDU
berman@VAXA.ISI.EDU
masinter.pa@Xerox.COM
Adler.pa@XEROX.COM
Bobrow.pa@XEROX.COM
pavel.pa@XEROX.COM
daniels.pa@XEROX.COM
gregor.pa@XEROX.COM
Ricci.pa@XEROX.COM
Sye.pasa@XEROX.COM
vittal.pasa@XEROX.COM
"JerryB%OZ"@XX.LCS.MIT.EDU
Hewitt@XX.LCS.MIT.EDU
"willc%tekchips@tek.csnet"@RELAY.CS.NET
"sridhar%tekchips@tek.csnet"@RELAY.CS.NET
"angela%gmdtub.uucp@Germany.csnet"@RELAY.CS.NET
"Bartley%TI-CSL"@RELAY.CS.NET
"Bate%TI-CSL"@RELAY.CS.NET
"Dussud%AUSOME%TI-CSL"@RELAY.CS.NET
"ida%utokyo-relay.csnet"@RELAY.CS.NET
"Waldrum%TI-CSL"@RELAY.CS.NET
"TURBA%sperry-csd.csnet"@RELAY.CS.NET
bawden@MC.LCS.MIT.EDU
RG@MC.LCS.MIT.EDU
"mike%acorn"@LIVE-OAK.LCS.MIT.EDU
"RSG%OZ"@AI.AI.MIT.EDU
JAR@MC.LCS.MIT.EDU
Soley@MC.LCS.MIT.EDU
"edsel!eb"@NAVAJO.STANFORD.EDU
"edsel!jonl"@NAVAJO.STANFORD.EDU
"edsel!jlz"@NAVAJO.STANFORD.EDU
fahlman@C.CS.CMU.EDU
RAM@C.CS.CMU.EDU
sgadol@Sun.COM
Muchnick@Sun.COM
CPerdue@Sun.COM
"quintus!gehrig!bak"@Sun.COM
Moon@SCRC-STONY-BROOK.ARPA
KMP@SCRC-STONY-BROOK.ARPA
DLW@SCRC-STONY-BROOK.ARPA
Goldstein@SCRC-STONY-BROOK.ARPA
ACW@SCRC-STONY-BROOK.ARPA
chaowatkins@SCRC-STONY-BROOK.ARPA
griss@HPLABS.HP.COM
"DCM%HPFCLP"@HPLABS.HP.COM
chapin@hplabs.hp.com
Krall@MCC.COM
Loeffler@MCC.COM
"Brown%Bach.Dec.Com"@DECWRL.DEC.COM
slater@umbc2.umd.edu
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:53 PST
Date: 19 Dec 1986 05:51-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: minutes of Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:51:46.MATHIS>
Gary Brown has already sent me the draft minutes of the Dallas
meeting. They seem very good, but he and I are still double
checking each other. If you want to see the preliminary version,
I will forward it to you; if you would rather wait, they will
come in about ten days. -- Bob Mathis
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:38 PST
Date: 19 Dec 1986 05:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes
Subject: [Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
sigh, sigh! Guy got this done, but to me on a day I was off the
net. He has inserted some sight additions. We should discuss
this on the net so that we can make a clean copy with clearly
specified alternate wordings so that we could vote on it point by
point at the next meeting. In Dallas I got the feeling that if
we had a clean text, it would probably be passed unanimously.
This is the chance for all of you (particularly those who could
not be in Dallas) to participate in the discussion. -- Bob
Mathis
Begin forwarded message
Received: FROM GODOT.THINK.COM BY USC-ISIF.ARPA WITH TCP ; 16 Dec 86 09:46:39 PST
from boethius by Godot.Think.COM via CHAOS; Tue, 16 Dec 86 12:45:00 EST
Date: Tue, 16 Dec 86 12:46 EST
From: Guy Steele <gls@Think.COM>
To: mathis@ada20.isi.edu
Cc: gls@AQUINAS
Subject: [gls@Think.COM: X3J13 charter (proposed)]
Return-Path: <gls@Think.COM>
Message-ID: <861216124628.6.GLS@BOETHIUS.THINK.COM>
Sigh. I mailed this Friday evening, but to the wrong address.
--Guy
----------------------------------------------------------------
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National
Standard for Common Lisp. It will codify existing practice,
provide extensions to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in
{\it Common Lisp: The Language} by Guy L. Steele Jr. (Digital
Press, 1984), which is the current {\it de facto} standard for
Common Lisp. Whenever there is a proposal for the standard to
differ from {\it Common Lisp: The Language}, the committee
shall weigh both future costs of adopting (or not adopting) a
change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in {\it Common Lisp: The Language}
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in {\it Common Lisp: The
Language} that require resolution. Topics (d) and (e) are not
addressed by {\it Common Lisp: The Language} but appear to be
well-understood and ready for standardization. Topics (f)-(i)
concern areas where standardization is desirable but not
crucial to production of a standard. Topic (j) is an area of
current controversy within the Lisp community. Other topics
may be considered if specific proposals are received.
4. The committee recognizes that Lisp programming practice
will continue to evolve and anticipates the need for future
revisions and extensions to the standard. This may include a
family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
[Possible amendment: change the word "extensions" in the first
paragraph to "additional features".]
--------------------
End forwarded message
∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 07:27:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Dec 86 10:26:34-EST
Date: Fri, 19 Dec 1986 10:26 EST
Message-ID: <FAHLMAN.12264051413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: proposed purposes
In-reply-to: Msg of 19 Dec 1986 08:46-EST from MATHIS at ADA20.ISI.EDU
Looks excellent to me.
The proposed ammendment (extensions -> additional features), seems like
a useful clarification.
-- Scott
∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Dec 86 08:31:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 86 08:31:11 PST
Date: 19 Dec 86 08:30 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: proposed purposes
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 19 Dec 86 05:46 PST
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <861219-083111-7132@Xerox>
I like this very much -- with the suggested change:
extensions --> additional features
It captures both the need for resolving the current set of issues
relatively quicly for the current community, and also possible futures
that could involve more work, but provide great benefit.
danny
∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:35:49 PST
Posted-Date: Fri 19 Dec 86 09:35:29-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22770; Fri, 19 Dec 86 09:35:30 PST
Date: Fri 19 Dec 86 09:35:29-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:35:29.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "additional
features" to "extensions".
Ron
-------
∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:58:18 PST
Posted-Date: Fri 19 Dec 86 09:43:35-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22910; Fri, 19 Dec 86 09:43:36 PST
Date: Fri 19 Dec 86 09:43:35-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:43:35.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "extensions"
to "additional features."
Ron
-------
∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 11:55:25 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17572; Fri, 19 Dec 86 11:55:23 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612191955.AA17572@vaxa.isi.edu>
Date: 19 Dec 1986 1155-PST (Friday)
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: proposed purposes,
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
In-Reply-To: Your message of 19 Dec 1986 05:46-PST.
<[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Me Like. Ugh.
RB.
∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 13:19:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32441; Fri 19-Dec-86 15:52:55 EST
Date: Fri, 19 Dec 86 15:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219155422.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
This looks fine. The spelling of "ommissions" should omit one of the
m's. I agree that "extensions" should be changed to "additional
features".
∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 20:17:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87742; Fri 19-Dec-86 23:15:26 EST
Date: Fri, 19 Dec 86 23:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219231549.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this is an excellent charter for X3J13. I approve of the
wording and especially of the attitude about what is important and the
choice to finish Common Lisp rather than embarking on a new experiment.
One comment on "establish normative Common Lisp programming practice":
I doubt it's actually possible to get such a large group of Lisp programmers
to agree in any meaningful way on issues of programming style. If this
goal is achieved, it will be a monumental accomplishment. My preference
would be to leave it to the professors and the authors of textbooks, but
I have no real objection. After all, some of the lettered items will be
fairly difficult to bring to closure too.
∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 18:49:07 PST
Received: by hplabs.HP.COM ; Mon, 22 Dec 86 14:07:40 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Mon, 22 Dec 86 10:24:52 mst
Date: Mon, 22 Dec 86 10:24:52 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Mon, 22 Dec 86 10:15 MST
To: hpfclp!x3j13@sail.stanford.edu
Subject: Charter statement
This may have already appeared from another source, I'm not sure since there
seems to be some problem with my mail address. Here is the text of Guy's
statement of purpose with some comments from the discussions. Words or
clauses that were topics of discussion are enclosed in []s. Additional notes
are indented after each item.
Dave Matthews
------------------------------------------------------------------------------
Revise draft 86-005
Purposes of X3J13 Committee (proposed)
1. X3J13 is chartered to produce an American National Standard for Common Lisp.
It will codify existing practice, provide [extensions] [necessary] to
[facilitate] portability of code among diverse implementations and [establish]
normative [Common] Lisp programming practice.
change establish to stabilize?
extensions is a loaded word, are they required or not, maybe features is
a better word?
should a stronger term than facilitate be used
are we really establishing a programming practice, including style, etc
2. The committee will begin with the language described in Common Lisp: the
Language by Guy L. Steele Jr., which is the current de facto standard for
Common Lisp. Whenever there is a proposal for the standard to differ from CLTL
the committee shall weigh both future costs of adopting (or not adopting) a
[feature] and costs of conversion of existing code. [Aesthetic criteria shall
be a subordinate consideration.]
feature might be better said as change
should the clause about aesthetics exist at all
3. The committee will address at least the following topics in the course of
producing the standard, in each case either incorporating specific features or
explaining why no action was taken:
a) repairing [errors/mistakes], ambiguities and minor omissions in CLTL
b) error handling/condition signalling
c) semantics of compilation
d) object-oriented programming
e) iteration [the LOOP] constructs
f) multiprocessing
g) graphics
h) windows
i) one or two name spaces for functions or values
j) validation
Topics (a)-(c) concern deficiencies in CLTL that require resolution. Topics
(d) and (e) are not addressed by CLTL but appear to be well-understood and
ready for standardization. Topics (f)-(h) concern areas where standardization
is desirable but not crucial to production of a standard. Topic (i) is an
area of current controversy in the LISP community.
Topic (j) is not currently clarified.
4. The committee recognizes that Lisp programming practice will continue to
evolve, and anticipates the need for future revisions and extensions to the
standard. This may include a family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international Lisp standard.
separated from item 4.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:05 PST
Date: 5 Jan 1987 17:12-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: 2nd meeting minutes X3J13/86-021
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:12:03.MATHIS>
DRAFT Minutes X3J13 Committee Meeting
Dates: December 10, 11, 12, 1986
Location: Sheraton Park Central Hotel, Dallas, Texas
Chair: Bob Mathis (acting)
Secretary: Gary Brown (acting)
Hour of opening: December 10, 1986 1:20 PM
Hour of adjournment: December 12, 1986 11:25 AM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None were prepared
Register of Documents: Attached
Motions seconded and not withdrawn:
Motion to formally thank Ellen Waldrum and Texas Instruments for
the meeting arrangements.
Moved by Dave Slater
Seconded by Peter Coffee
Unanimously approved
Future meeting schedule:
The next meeting is scheduled for March 16, 17 and 18, 1987 in Palo
Alto, California. Dick Gabriel will make the arrangements.
List of action items assigned to committee members:
Working groups were formed for eleven areas requiring investigation
and a convenor was assigned for each group. These groups are
informally charged with bringing evaluation and recommendations back
to the full committee. The body of the minutes lists the groups
and their convenors.
Meeting Summary:
Call to Order:
The meeting was called to order at 1:20 PM.
Opening remarks:
Bob Mathis specified significant dates for X3J13:
December 30, 1986: Wrapup mailing for second meeting
January 9, 1987: Minutes for second meeting due
January 15, 1987: Membership fees due (however no one has
yet received bills)
February 4, 1987: Deadline for next meetings mailing
February 10, 1987: Mailing for meeting 3
Bob Mathis introduced himself discussed his background. All attendees
then introduced themselves.
Approval of agenda:
The agenda, X3J13/86-016, was approved without objection.
Approval of minutes:
The minutes of the first meeting (September 23-24) were not available.
Report on International Activities:
Bob Mathis attended SC22 in Vienna and reported on that meeting.
The major decision was that an ISO Lisp committee would be formed
with a convenor from France and a project editor from the United
States.
Dick Gabriel reported on the "EuLisp" meeting in Paris. The
"EuLisp" group intends to work through ISO and Christian Queinnec
would be group convenor. Several technical issues were also
discussed at the Paris meeting and it is obvious that there
are some technical differences between the initial "EuLisp"
proposal and Common Lisp.
Other liaisons reports:
Bob Mathis asked if there were any volunteers to review:
o Guidelines for programming language conformity and testing
o Programming language standards document standard (i.e. a standard
for how a standard should be written)
Mathis also reported that DEC Press would cooperate with X3J13 in
preparation of standards document. However, initial discussions
with ANSI on allowing the "free" distribution of the standard
document were not encouraging.
Review of Goals and Objectives (86-005):
Approximately an hour and a half was spent discussing the proposed
goal statement for X3J13. Issues raised included:
o the relationship between X3J13 and an ISO Lisp standard effort
o conservative vs ambitious planning and language design
o de-facto vs real standards
Various committee members contributed opinions and historical anecdotes.
No formal motions were made.
Overview of technical topics.
Dick Gabriel gave a brief overview of issues surrounding function
and value cell separation. Kent Pitman gave a overview of the
proposed condition handling system.
Recess:
The meeting was recessed on December 10, 1986 at 5:30 PM.
Call to Order:
The meeting was resumed on December 11, 1986 at 9:07 AM.
Function/Value Cells (86-010):
Dick Gabriel presented the technical issues raised in "Issues of
Separation in Function Cells and Value Cells" (86-010). This topic
was dsicussed for two and a half hours.
Lunch:
The meeting was recessed for lunch from 11:45 AM to 12:50 PM.
Goals and Objectives:
Danny Bobrow presented some alterations to the "Goals and Objectives".
These proposed changes included:
o Stating that X3J13 would work on two fronts; ANS standard for Common
Lisp and working with ISO to prodcue Lisp standard for the longer term.
o Stating we would address other areas such as windows, graphics and
multi-processing
Jerome Chailloux gave his opinions on the goals for X3J13.
Error Systems:
Kent Pitman presented a description of the proposed Common Lisp
Condition handling system. Discussions lasted an hour and fifteen
minutes. Kent believes this proposal is relatively firm and a
final specification will be available soon.
Update on object systems:
Danny Bobrow presented the status of the proposed Common Lisp
object subsystem. The major change between current design and
what was previously proposed is no longer using DEFSTRUCT for
object definition but instead using two new macros; DEFRECORD and
DEFCLASS. Danny believes that this work is progressing well and
expects convergence before the next meeting.
Goal and Objectives:
Approximately half an hour was spent in another open discussion
X3J13 of Goals and Objectives. Bob Mathis suggested that an
ANS standard separate from ISO might be rejected by X3.
Recess:
The meeting was recessed on December 11, 1986 at 5:15 PM.
Call to Order:
The meeting was resumed on December 12, 1986 at 9:10 AM.
The committee voted to formally thank Ellen Waldrum and Texas
Instruments for the meeting arrangements.
Handling Technical Issues:
Bill Scherlis reported on the reccommendations of a subgroup formed
to discuss effective ways for X3J13 to discuss and decide issues.
They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person speicified is
the acting chair for each group [other initial members are listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk, Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
Goal and Objectives:
Guy Steele presented the recommendation of a subgroup formed
to create another draft of the Goals and Objectives statement for
X3J13. Here is a draft of this document:
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
features to facilitate portability of code among diverse
implementations and establish normative Common Lisp practice.
2. The committee will begin with the language described in "Common
Lisp: the Language" by Guy L. Steele Jr., which is the current
"de facto" standard for Common Lisp. Whenever there is a
proposal for the Standard to differ from CLtL, the committee
shall weigh both future costs of adopting (or not adopting)
a change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities and minor omissions in CLtL
(b) Error handling/condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration construct(s)
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) One or two namespaces for functions and values
(j) Validation
Topics (a)-(c) concern deficiencies in CLtL that require resolution.
Topics (d) and (e) are not addressed by CLtL but appear to be
well understood and ready for standarization. Topics (f)-(h)
concern areas where standarization is desirable but not crucial
to production of a standard. Topic (i) is an area of current
controversy within the Lisp community. Other topics may be
considered if specific proposals are received.
4. The comittee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
A discussion of this proposal took place followed by an informal
"sense of the committee" vote. The committee overwhelmingly
accepted this proposal. A final draft of this will be prepared
for a formal vote at the next meeting.
Call for officer candidates:
The following committee members are standing for X3J13 elected offices:
o Chair - Bob Mathis
o Vice-chair - Guy Steele
o International Representative - Dick Gabriel
Future meeting Schedule:
The next meeting will be March 16-18, 1987 in Palo Alto, California.
Adjournment:
The meeting was adjourned on December 12, 1986 at 11:25 AM.
Respectfully Submitted,
Gary L. Brown
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:30 PST
Date: 5 Jan 1987 17:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes X3J13/86-020
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:15:45.MATHIS>
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
extensions [amendment: change the word "extensions" to
"additional features".] to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:26:57 PST
Date: 5 Jan 1987 17:03-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: general letter X3J13/86-022
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:03:23.MATHIS>
Doc. No.: X3J13/86-022
Date: 86-12-30
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To everyone on the X3J13 (Common Lisp) mailing list:
This letter is being sent out in three different configurations: by
electronic mail to <x3j13> at SAIL (to everyone on that list), by regular
mail with enclosures (to everyone who has given an indication of
participation), and by regular mail without enclosures (to those on the
mailing list who have never responded). People who receive this letter
without enclosures, need to respond to this letter to remain on the mailing
list. Membership on X3J13 is open, but is based on a commitment to
continuing participation.
The Draft minutes of the Dallas meeting are enclosed (Doc: X3J13/86-021).
Thanks to Gary Brown. Included there is the list of initial members in the
task groups we formed (this was also the content of a separate electronic
message). Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed. At least part of the reason for
not forming the ISO interaction group was that the US delegation to the ISO
working group has not been chosen. Anyone from X3J13 is eligible if they
can make the additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation, please
contact me; Mathis, Gabriel, and Clinger have already expressed their
interest.
The acting chairs are to make sure that the members of their group
communicate with each other. If it is appropriate that a group set itself
an agenda and select a leader, the acting chair should make sure it
happens. Each of these groups will be called on for a BRIEF report at the
next meeting. If that report will be any more than just an affirmation of
existence, please contact me for scheduling.
As a separate document (Doc: X3J13/86-020) the draft proposed purposes are
also enclosed. This differs slightly from the version in the minutes; it is
X3J13/86-020 (or its revision) that we will be considering at the next
meeting. This has also been circulated electronically.
You (that is people who received enclosures with this letter or who respond
to this letter) will be sent the other documents resluting from the Dallas
meeting separately.
If you have any comments or other documents you want circulated before the
next meeting, please send them to me by February 4, 1987.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 07:19:23 PST
Date: 6 Jan 1987 07:13-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: task groups
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 6-Jan-87 07:13:41.MATHIS>
This has been covered in my over messages, but
is also being sent separately for emphasis.
-- Bob
At the meeting in Dallas, we decided to form some subgroups
(working groups, task groups, committees, or whatever name). What
follows is a section from the draft minutes giving the initial
structure of these groups. (Thanks to Gary Brown for getting the
minutes ready so promptly.) Others are free to join these groups,
but the size of each group should remain reasonable and
individuals should recognize they are making a commitment by
joining.
Bill Scherlis reported on the recommendations of a subgroup
formed to discuss effective ways for X3J13 to discuss and decide
issues. They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person specified is
the acting chair for each group [other initial members are
listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk,
Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
[At least part of the reason for not forming the ISO interaction
group was that the US delegation to the ISO working group has not
been chosen. Anyone from X3J13 is eligible if they can make the
additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation,
please contact me; Mathis, Gabriel, and Clinger have already
expressed their interest.]
[The acting chairs are to make sure that the members of their
group communicate with each other. If it is appropriate that a
group set itself an agenda and select a leader, the acting chair
should make sure it happens. Each of these groups will be called
on for a BRIEF report at the next meeting. If that report will be
any more than just an affirmation of existence, please contact me
for scheduling.]
∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 21:56:12 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 21:55:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01003; Tue, 6 Jan 87 21:48:53 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA16556; Tue, 6 Jan 87 21:46:18 PST
Date: Tue, 6 Jan 87 21:46:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701070546.AA16556@bhopal.edsel.uucp>
To: navajo!MATHIS%ADA20.ISI.EDU@navajo.stanford.edu
Cc: navajo!x3j13%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
[Sorry for the late entry of this comment -- I sent it out over two weeks
ago, and it got "bounced back" from some mail gateway at Stanford after
a few days of mailer problems; also, I've been "out of action" for
the past two weeks.]
Return-Path: <jonl>
Date: Fri, 19 Dec 86 11:27:59 PST
From: jonl (Jon L White)
To: navajo!MATHIS%ADA20.ISI.EDU
Cc: navajo!x3j13%SAIL.STANFORD.EDU
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
At Dallas, there was question about the first paragraph wording:
". . . establish normative Common Lisp programming practice."
Just what does that mean? and how can a committee "establish" it?
Someone suggested that that phrase was a replacement for some nebulous
statement about "portability of programmers", or "portability of skills".
If that is indeed the goal, then it's hard to see how a committee can
"establish" it -- I remember a suggestion being offered to re-word the
whole sentence roughly as follows:
"It will codify existing practice, provide additional features to
enable the portability of code among diverse implementations,
and facilitate the establishment of normative Common Lisp
programming practice."
-- JonL --
∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 13:29:03 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Jan 87 16:28-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 24905; 15 Jan 87 16:14:20-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 51643; Thu 15-Jan-87 14:31:21-EST
Date: Thu, 15 Jan 87 14:31 est
Sender: mike@acorn
To: x3j13@sail.stanford.edu
From: mike%acorn@mit-live-oak.arpa
Subject: Document 86-019
Note: You will be receiving hardcopy of the following from Bob Mathis.
----------------------------------------------------------------------
!
To: ANSI x3j13
From: Mike Beckerle, Gold Hill Computers
Date: 1/13/87
Subject: Document x3j13/86-019
Since my draft proposal which was hastily drawn up at the last x3j13
meeting, I have had time to reconsider several points in my proposal
for adding a few features to CL to support Higher-Order Functional
Programming. I have also decided to bring up the meta issue in this
forum.
The meta-issue is this: Would adding enough syntactic accommodation
to Common Lisp to make functional programming palatable defuse this
Lisp1 vs. Lisp2 debate enough? Or more optimistically, what level of
accommodation for programming with functionals would in fact defuse
this issue. For example, Would it be enough to provide the following:
Programs written in in a Lisp1 "educational/functional" dialect would
not be directly upwardly compatible with ANS Common Lisp; however,
the changes required would be straightforward to make and
syntactically convenient. (We know that they can't be automatic due
to use of EVAL.) I am particularly trying to address the issues of
Appendix B, section 6 of the "Issues..." paper.
What I'm trying to get at here is this: Why do people want a
"one-cell" lisp? Is it because it promotes/allows effective
programming using higher-order functions (style), because it is
more consistent/cleaner and therefore easier to understand and
teach (conceptual economy), because they are more familiar with a
one-cell lisp than a two cell lisp (momentum), because of a
purely aesthetic view that one cell is "better" (aesthetics),
because they don't like the name-capture problems of
common-lisp's so called "non-hygienic" macros (macrophobia), or
finally because they want political clout (politics).
My approach addresses that the push for lisp1 is due at least
partially to aesthetics but primarily is due to the style issue.
The following is a proposal for adding a small number of features
to Common Lisp to accommodate programming using higher-order
functions, or functionals. Functional programming is much easier
in a Lisp1 dialect than a Lisp2 dialect since functional
programming makes extensive use of functions as values. Common
Lisp's current (Funcall ...) and (Function ...) or #' syntax
makes functional programming particularly awkward. In addition
the fact that one cannot write an application which produces a
function in the car of a list representing an application is a
pain. [let's call this the "((f g) h)" problem.] These features
are intended to accommodate the functional style, without changing
the language too radically from the current status defined in
CLtL.
---------------------------------------------------------------------
!
Document x3j13/86-019
Accommodating Functional-Style Programming in Common Lisp.
Mike Beckerle
Gold Hill Computers
Jan. 6, 1986.
One of the primary motivations for use of Lisp1 dialects is the
ease of higher-order programming. Many of the examples of
effective programming practice in Lisp1 given in the "Issues of
Separation in Function and Value Cells" paper recently discussed
by x3j13 at the Dec. '86 meeting are exactly of this type.
Unfortunately, macro programming in Lisp1 dialects is not well
understood and is a subject of current research; nevertheless
macro programming is heavily entrenched in the Common lisp world.
As a result, the approach advocated in this proposal is to
provide some standard operators and macros which make programming
using higher-order functions in Common Lisp significantly easier.
The Changes to CL as defined in CLtL are enumerated here, after
which there are some examples.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
beginning with something other than LAMBDA it should be
interpreted as an application itself.
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
and
(funcall ((lambda (x) x) #'(lambda (y) y)) 10))
in the current CL as per CLtL.
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions. Lambda
expressions evaluate to functions. Function applications must
evaluate to either functions or symbols. If they evaluate to
symbols, then (recursively) the function definition of that
symbol is used.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
!
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
The FUNCTION special form is needed only to distinguish between
the function and value of symbols which are either globally
referenced or locally bound using one of FLET, LABELS, MACROLET,
parameter passing, LET, LET*, and MULTIPLE-VALUE-BIND.
!
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This allows use of the CL symbols which name CL functions in
variable position without need for the FUNCTION special form as
in (mapcar list '(a b c) '(d e f)). If the value of the variable
"list" is locally bound to a function, possibly using let, then
the local definition will be used in accordance with the rules of
lexical scoping.
The primary change this requires is the renaming of certain
symbols of significance to the standard read-eval-print loop.
I suggest that the following renamings be used:
+ => +1
++ => +2
+++ => +3
- => -- or _ ;; this one's difficult to get a nice name for!
* => *1
** => *2
*** => *3
/ => /1
// => /2
/// =? /3
The behavior of these variables would be identical to the current
behavior of the old-named variables. I consider this change to
be simply cosmetic, aesthetic, etc. No program of any quality
(other than those written as read-eval-print loops by
implementors) ever uses these variables. (Unfortunately, the
Peter Principle dictates that the least significant point always
gets the most debate, so I'm prepared for absolute tirades on
this one! Please restrain yourselves!!!!!)
!
Change 4: Section 7.11. Use of Higher-order Functions
Organizationally, this seems to belong in the chapter 7
discussion, so I've proposed a new section for that chapter
in lieu of any guidelines for how to present standards proposals.
The text as a preliminary draft follows:
"Common Lisp provides some support for programming using higher-
order functions. These allow the programmer to partially hide the
distinction between function-cells and value-cells and to program
as if using a language where only one cell is associated with
each symbol. The objective is to make the syntax of higher-order
programs easier to read and understand. The abstraction that this
creates is not complete; it is possible for programs to detect
that there are separate function and value cells even when these
abstractions are used; however, the syntactic convenience of
using these forms where they are applicable is significant.
FUNCTIONAL Vars* {form}* [Macro]
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
For example:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
Here, notice that "f" and "g" are used both as variables
representing functions, and also as functions, as if defined by
FLET or LABELS.
One possible definition for FUNCTIONAL is:
(defmacro functional (vars &body body)
(let* ((bindings (mapcar #'(lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
Implementation note: FUNCTIONAL can also be implemented
using MACROLET.
Care is required if FUNCTIONAL is used in programs which perform
side-effects on symbols via SYMBOL-FUNCTION or SYMBOL-VALUE. The
behavior of the resulting program can be difficult to predict."
!
Change 5: Section 7.1.1. (again)
Note: The following is the least kosher aspect of this proposal,
but I am including it anyway. Once again it is written as an
addition to section 7.1.1. Its intended use is for defining new
named functions which will be associated with both function and
value cells of symbols, thereby forming a consistent extention.
In general, use of side-effects within higher-order programs is
extremely tricky; one tends to program in a pure style out of
necessity.
SYMBOL-CONTENTS symbol [Function]
In order to facilitate programming in the functional style it is
often useful to ignore the function-cell/value-cell aspect of
symbols. Symbol-contents, if used consistently throughout an
entire program can facilitate this style of programming.
The function Symbol-contents can be used to extract or replace the
value of a symbol in a manner which is indifferent to the
normal CL distinction between function cells and value cells.
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
Symbol-contents cannot access nor assign (using setf) the value
of local symbol or function definitions created using let, flet, labels,
let*, etc. Only the global value can be accessed or modified.
It is an error to execute code which calls a function named by a symbol
where that symbol has been assigned a value other than a function object
via setf of symbol-contents.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
--------------------------------------------------------------------
!
Use of the Higher-order function extensions to CL.
To show the utility of these abstractions in higher order
programming, it is important to look at some example programs.
Hence, I have rewritten the examples in Appendix B of
the "Issues of Separation in Function Cells and Value Cells"
using Common Lisp with the proposed extensions.
;;;---------------------------------------------------------------------
;;; from Appendix B: "High-Order Procedures for Functional Abstractions"
;; our macro for making functional programming easier.
(defmacro functional (vars &body body)
(let* ((bindings (mapcar (lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
;; a macro which obviates #' notation.
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
;; the symbol-contents function and its setf.
(defun symbol-contents (name)
(symbol-value name))
(defun set-symbol-contents (name value)
(setf (symbol-value name) value)
(setf (symbol-function name) value))
(defsetf symbol-contents set-symbol-contents)
;; a DEFINE macro, syntactic sugar to make the examples
;; more scheme-like. Doesn't put implicit blocks on lambda's,
;; doesn't handle local defines. This could be done, but we won't bother
;; here.
(defmacro define (name value)
`(setf (symbol-contents ',name) value))
;; misc.
(defun null? (x) (null x))
(defun future (x) x)
(defun assq (x y)
(assoc x y :test 'eq))
;;--------------------------------------------------------------------
!
;; The example programs.
;; these have been translated slightly from Scheme to Common Lisp
;; plus my suggested extentions.
(define sum
(lambda (f a next b)
(functional (f next)
(if (> a b)
0
(+ (f a)
(sum f (next a) next b))))))
(define integral
(lambda (f a b dx)
(functional (f)
(* (sum f (+ a (/ dx 2)) (lambda (x) (+ x dx)) b)
dx))))
(define map
(lambda (f x)
(functional (f)
(if (null x)
nil
(cons (f (car x))
(map f (cdr x)))))))
(define reduce
(lambda (f l)
(functional (f)
(if (null? (cdr l))
(car l)
(f (car l)
(reduce f (cdr l)))))))
(define pairs
(lambda (x k)
(functional (k)
(if (or (null? x) (null? (cdr x)))
(k nil x)
(pairs (cddr x)
(lambda (p r)
(k (cons (list (car x) (cadr x))
p)
r)))))))
(define reduce
(lambda (f x)
(functional (f)
(pairs x
(lambda (p r)
(if (null? p)
(car r)
(reduce f
(append (map (lambda (z)
(future (apply f z)))
p)
r))))))))
(defstruct (table-abstraction
(:constructor make-table-abstraction
(maker looker-up inserter))
(:conc-name nil))
maker looker-up inserter)
(defun hashfunction (n)
(lambda (x)
(mod (sxhash x) n)))
(define hashify
(lambda (n table-abstraction)
(let ((hash (hashfunction n))
(bucket-make (maker table-abstraction))
(bucket-lookup (looker-up table-abstraction))
(bucket-insert! (inserter table-abstraction)))
(functional (hash bucket-make bucket-lookup bucket-insert!)
(let ((make
(lambda ()
(let ((hashtable (make-array n)))
(dotimes (i n)
(setf (aref hashtable i)
(bucket-make)))
hashtable)))
(lookup
(lambda (key table)
(bucket-lookup key
(aref table
(hash key)))))
(insert!
(lambda (key table value)
(bucket-insert! key
(aref table (hash key))
value))))
(make-table-abstraction make lookup insert!))))))
(defun make-entry (key value) (cons key value))
(defun set-value! (vcell value) (rplacd vcell value))
(define alist-table-abstraction
(make-table-abstraction
(lambda () (list '*alist-table*))
(lambda (key table)
(cdr (assq key (cdr table)))) ;; alist of cons pairs
(lambda (key table value)
(let ((vcell (assq key (cdr table))))
(if vcell
(set-value! vcell value)
(rplacd table
(cons (make-entry key value)
(cdr table))))))))
(define hash-table-of-alists-abstraction-generator
(lambda (n) (hashify n alist-table-abstraction)))
(define hash-table-of-alists
(hash-table-of-alists-abstraction-generator 16))
(define two-level-hash-table-abstraction-generator
(lambda (m n table-abstraction)
(hashify m (hashify n table-abstraction))))
(define two-level-hash-table-of-alists-abstraction-1
(two-level-hash-table-abstraction-generator
128 256 alist-table-abstraction))
;;-----------------------------------------------------------------
My observation is that using the FUNCTIONAL abstraction along with the
ability to perform applications which syntactically look like "((f g) h)"
makes the enhanced CL version pretty close to the Lisp1 version at least
as far as syntactic aesthetics are concerned.
∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:15:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44898; Thu 15-Jan-87 23:13:42 EST
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
In-Reply-To: The message of 15 Jan 87 14:31 EST from mike%acorn@mit-live-oak.arpa
Message-ID: <870115231337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:21:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 Jan 87 11:21:29-EST
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 11:24:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 87 11:24:00 PST
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
Message-ID: <870116-112400-2364@Xerox>
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:55:29 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ab04827;
17 Jan 87 0:43 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA04079; Fri, 16 Jan 87 21:25:51 PST
Received: by tekchips.TEK (5.31/6.16)
id AA12223; Fri, 16 Jan 87 14:56:26 PST
Message-Id: <8701162256.AA12223@tekchips.TEK>
To: x3j13@SU-AI.ARPA
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Document 86-019
In-Reply-To: Your message of Thu, 15 Jan 87 14:31 est.
<8701160757.AA02526@tekchips.TEK>
Date: 16 Jan 87 14:56:21 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mike Beckerle asked some interesting questions and suggested some possible
answers. Ultimately, he is asking for a philosophy of programming language
design. Here's mine.
* * *
Programming is hard because it's hard to know what you want the machine
to accomplish (the problem), and it's hard to know how to accomplish it
(the algorithm). If you knew these two things, it ought to be easy to
program the machine to do what you want.
It usually isn't. The reason is that you have to learn all sorts of arcane
things about the computing environment and programming language that you
use. These details have nothing to do with the problem you're trying
to solve. Even so, they may be almost as difficult to master.
Most people, being reasonable, don't try to master their programming
language completely, particularly if their programming language is big
and complicated. In my experience, the main thing that a programming
language can do for these people is to be consistent with a simple mental
model that they can use without getting into trouble. Extra features
that help people get their work done more easily are nice, but it is more
important that the language not get in their way. It is most important
that the language not be full of nasty surprises for its users.
This principle of programming language design is sometimes known as the
"Law of Least Astonishment", in waggish recognition of the fact that even
the best design efforts are ad hoc in part. Its motivation is very
pragmatic, its application very practical. It says that simplicity,
elegance, and aesthetics pay off.
* * *
In answer to some of Mike's specific questions, people prefer a single-
environment Lisp because of style, conceptual economy, and aesthetics; I
see little difference between conceptual economy and aesthetics, which is
perhaps a clue to my sense of aesthetics. Inertia can't be the reason,
since most of us who prefer the single environment were once more familiar
and comfortable with two-cell Lisps. Macros don't have anything to do with
this issue, so macrophobia can't be the reason; if anything, the problems
with Common Lisp-style macros are exacerbated by a single environment.
Speaking for myself, politics isn't the reason I prefer a single
environment; rather my preference for a single environment, the current
preponderance of political clout on the side of multiple environments,
and the use of that clout in the current push for Lisp standards are the
reasons I myself now seek political clout.
* * *
Mike's other question asks whether enough syntactic sugar could be added
to Common Lisp to make functional programming palatable. Well, Common
Lisp certainly could be improved in this respect, and I second David
Moon's remarks on changes 1 and 2.
As for changes 3, 4, and 5, these changes seem designed to make it possible
to program as though Common Lisp were a Lisp1 dialect, but they only go
part of the way. You might be able to go all the way by doing things like
defining the LAMBDA macro so it automatically wraps an equivalent of the
FUNCTIONAL macro around its body, by defining a SET! special form that
assigns to both the value and functional bindings (which, by the way, can't
easily be written in Common Lisp as it stands because only global functional
bindings can be assigned), and so on. This would amount to implementing
a Lisp1 sublanguage inside Common Lisp. Unless you're willing to go
all the way to that Lisp1 sublanguage, I think it's a bad idea to try
to paper over the fact that Common Lisp has multiple environments.
If the changes go only part of the way, and we teach people to use the
proposed syntax and encourage them to think about Common Lisp as though
it is a Lisp1 dialect, then they will probably end up getting burned
even more often than they do now. Even people who understand full well
that Common Lisp has multiple environments might slip into the cozier
Lisp1 mode of thought and get burned by the Lisp2 reality.
It's the law of least astonishment: A Lisp2 dialect that looks like a
Lisp1 dialect 98% of the time may be worse than a straightforward Lisp2
dialect.
Peace,
William Clinger
∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂10-Feb-87 0246 RPG Registration
To: x3j13@SAIL.STANFORD.EDU
Don't forget to register for the March meeting. Registration closes
in a couple of weeks and right now there are only a handful registered.
-rpg-
∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 19:46:39 PST
Date: 12 Feb 1987 11:35-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: plans for Palo Alto and mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Feb-87 11:35:35.MATHIS>
Today I put the following in the US mail to our physical mailing list.
Most of the documents referenced can also be had electronically. Two
items of particular interest follow -- the cover letter and the DRAFT
agenda (please send me any further detail you may have for a revised
agenda):
Doc. No.: X3J13/87-006
Date: 87-02-10
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To X3J13 (Common Lisp) participants:
Enclosed are some of the documents relating to the upcoming
meeting in Palo Alto, CA on March 16-18, 1987. Most of you are on
the electronic mailing list and should have seen most of this
earlier. In particular hotel reservations are due about the time
you will probably receive this letter.
Dick Gabriel will be sending out information relative to the
objects proposal separately and directly [documents 87-002 and
87-003].
Notice that there is a revised version of Doc: 86-020 on Purposes
included with document 86-023. This includes some of the comments
that I saw on the net reproduced in a way that will hopefully
facilitate their consideration. If you have other comments or
changes that you may want to suggest at the meeting, please bring
about 50 copies for distribution there. I expect some action will
be taken on this document at the meeting.
Documents 86-017 and 86-018 are from the infamous lost boxes of
Dallas.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Enclosures:
86-017 Excerpts from ISO/TC97/SC22 ad hoc report re Lisp
86-018 Papers from Symbolics re objects and flavors
86-019 from Mike Beckerle
86-020R included with 86-023
86-023 Comments on Purposes document 86-020
86-024 Comments on Lisp1/Lisp2 issues
87-000 Document Register for 1987
87-001 Document Register for 1986
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
SD-04 Meeting Schedule
Note: 87-002 and 87-003 being mailed separately.
Proposed Agenda X3J13/87-005
AGENDA -- Day 1
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
1 Call to Order, March 16, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda (87-005)
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-025)
5 Approval of Minutes of Dec 10-12 Meeting (Doc: 86-021)
6 Report on International Activities (Doc: 86-017)
7 Other Liaison Reports
8 Action on Goals and Objectives (Doc: 86-020R and 86-023)
9 Reports from Task Group Chairmen
10 Recess, 5:00pm
AGENDA -- Day 2
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
11 Call to Order, March 17, 9:00am
12 Discussion of Objects Proposal (87-002 and 87-003)
13 LUNCH Second Day, 12:00-1:00pm
14 Continued Objects Discussion (87-002 and 87-003)
15 Recess, 5:00pm
AGENDA -- Day 3
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
16 Call to Order, March 18, 9:00am
17 Additional Reports from Task Group Chairmen
18 Future Meeting Schedule (Doc: SD-04)
19 Review of Action Item Assignments
20 Adjournment, 12:00noon
∂27-Feb-87 1453 RPG X3 registration list 2/27/87
To: x3j13@SAIL.STANFORD.EDU
Below is the list of people I have heard from, hotel dates and
whether registration fees have been paid. Please check the
list and let me know if you disagree with any information about
yourself.
---jan---
Registration/Hotel List
02/27/87
Name Company Check In Check Out Paid
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- -
Gary Brown Digital 03/15/87 03/18/87 y
Jerome Chailloux INRIA -0- -0- -
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 -
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Kevin Layer Franz Inc. -0- -0- y
Bob Mathis DARPA 03/14/87 03/19/87 y
Ronald Ohlander USC/ISI -0- -0- y
Crispin Perdue SUN MicroSystems -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:13:46 PST
Posted-Date: Fri 27 Feb 87 15:14:12-PST
Received: by venera.isi.edu (5.54/5.51)
id AA03315; Fri, 27 Feb 87 15:14:12 PST
Date: Fri 27 Feb 87 15:14:12-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 registration list 2/27/87
To: RPG@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 27-Feb-87 15:14:12.VENERA.ISI.EDU>
In-Reply-To: Message from "Dick Gabriel <RPG@SAIL.STANFORD.EDU>" of 27 Feb 87 1453 PST
Dick,
I will check in on the evening of the 17th of March and check out on the 18th
of March. I have made my room reservation independently.
Ron
-------
∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:51:19 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17152; Tue, 3 Mar 87 12:51:59 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032051.AA17152@vaxa.isi.edu>
Date: 3 Mar 1987 1251-PST (Tuesday)
To: berman@vaxa.isi.edu (Richard Berman)
Cc: X3J13@su-ai.arpa
Subject: Re: Who's Where?
In-Reply-To: My message of 2 Mar 1987 1332-PST (Monday).
<8703022132.AA05893@vaxa.isi.edu>
A few days ago I asked for the members of the X3J13 subgroup on validation to
please send me their current net address as part of a message (as opposed to
just having the mailer automatically generate one). So far Mike Beckerle and
John Foderaro have responded. Could Jon L. White and David Slater please
respond, as well as any others???
Thanks a bunch.
RB
∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 13:59:30 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17899; Tue, 3 Mar 87 13:59:42 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032159.AA17899@vaxa.isi.edu>
Date: 3 Mar 1987 1359-PST (Tuesday)
To: Marick@GSWD-VMS.ARPA
Cc: berman@vaxa.isi.edu, cl-validation@su-ai.arpa, X3J13@SU-AI.arpa
Subject: Validation
> I'm not going to respond to your message until you respond to mine.
> I just spent a weekend rewriting sequence function tests and,
> consequently, rewriting some sequence functions. I am more convinced
> than ever that a test suite should predate publication of a standard
> -- there's at least one other sequence function besides *ASSOC* that's
> underspecified. (Unfortunately, I didn't write it down, and I've
> forgotten which one, now.)
> Does the deafening silence mean consent?
Brian, let me know if this gets through. I have been responding to messages,
but sending them to marrick%cthulhu@gswd-vms.arpa has not worked.
I don't know that a test suite should *predate* standard publication, but it
should be part of that publication. In fact, when formally published it would
be a good idea to for the standard and the test-suite to cross reference each
other. That is, the each test should test a specific clause (or clauses?) of
the standard. The standard should also include forms which must evaluate in a
certain way where this is meaningful to the definition of some part of the
standard. In these cases the form would be part of the test suite.
HOWEVER....
I believe it is possible to have a useful test suite before the standard is
finalized and published. I am preparing a report now for the X3 meeting that
will outline some possible stages in the development of the test suite. Part
of our problem is that we are aiming at a moving target...
Best,
RB
∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 14:14:45 PST
Date: 7 Mar 1987 14:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: agenda update
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 7-Mar-87 14:15:02.MATHIS>
Although I will not be making a revised agenda, on Monday, March
16, we will be having a report from Masayuki Ida on activities in
Japan, a report from Bob Balzer and Rich Berman on validation
developments, and I expect an initial report from the clean-up
committee which will probably continue on Wednesday morning. If
any of you have any last minute things to let me know about,
please send net mail before Saturday morning or contact me at the
hotel beginning Sunday. -- Bob
∂12-Mar-87 2210 RPG Final Attendee List
To: x3j13@SAIL.STANFORD.EDU
Here is the current list. See you Monday!
Registration/Hotel List
03/12/87
Name Company Check In Check Out Paid
John Allen The Lisp Co. -0- -0- y
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Richard Berman USC/ Information 03/16/87 03/19/87 y
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- y
Gary Brown Digital 03/15/87 03/18/87 y
Mike Cannon Hewlett-Packard -0- -0- y
Jerome Chailloux INRIA -0- -0- -
Chip Chapin Hewlet-Packard -0- -0- y
William Clinger Tektronics 03/16/87 03/18/87 y
Peter Coffee Aerospace Corp. 03/16/87 03/17/87 -
Pavel Curits Xerox AIS -0- -0- y
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 y
Andrew Daniels Xerox AIS -0- -0- y
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Jed Harris Intel -0- -0- y
Liz Heron IBM -0- -0- -
Carl Hewitt MIT 03/15/87 03/19/87 y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Sonya Keene Symbolics, Inc. -0- -0- y
Jim Kempf Hewlett-Packard -0- -0- y
Gregor Kiczales Xerox PARC -0- -0- -
Kevin Layer Franz Inc. -0- -0- y
Jim Lin IBM -0- -0- -
Thom Linden IBM -0- -0- y
Barry Margolin Thinking Machines 03/15/87 03/19/87 -
Larry Masinter Xerox PARC -0- -0- y
Bob Mathis 03/14/87 03/19/87 y
David Matthews Hewlett Packard -0- -0- y
David Moon Symbolics, Inc. -0- -0- y
Ronald Ohlander USC/ISI 03/17/87 03/18/87 y
Bob Pellegrino Prime Computer, 03/15/87 03/19/87 y
Crispin Perdue SUN MicroSystems -0- -0- y
Kent Pitman Symbolics -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
Angela Sodan GMD -0- -0- y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
Mark Wegman IBM T.J. Watson -0- -0- y
Dan Weinreb Symbolics, Inc. -0- -0- y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 02:04:49 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA08145; Fri, 13 Mar 87 02:05:31 PST
Message-Id: <8703131005.AA08145@decwrl.dec.com>
Date: Friday, 13 Mar 1987 02:03:29-PST
From: brown%bizet.DEC@decwrl.DEC.COM
To: x3j13@SAIL.STANFORD.EDU
Subject: Technical Editor
The major conclusion arrived at from thinking about writing the
standard is that a technical editor is required. This person's
job would be to convert CLTL to an approved format, distribute
copies, and incorporate approved changes and new material - basically
to control the sources to the standard. This is clearly a full-time job.
DEC is willing to hire someone to do this job for, at least, the
first year. However, before hiring someone to do it, we need to know
if this is acceptable to the committee. Please consider this offer,
and let me know when we meet next week.
-Gary Brown
∂13-Mar-87 0852 RPG Writer
To: x3j13@SAIL.STANFORD.EDU
This is the kind of spirit of volunteerism that is required to
make our task succeed. I encourage others to note this offer and
consider what they themselves can do.
Because this committee as a whole has oversight over the writer,
I can see no objections whatever. Possibly we'll want to nominate
an editor or two to work with the writer and exercise immediate
direction?
-rpg-
∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:40:27 PST
Date: 18 Mar 1987 13:40-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: draft minutes Palo Alto meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:40:53.MATHIS>
These are still quite rough, but Mary and I wanted to get them out fast.
Please send me your reactions and comments.
1:00pm ITEM 1 - Monday, March 16, 1987. Palo Alto meeting called to order.
ITEM 2 -Mathis - introductory remarks. New documents and missing Dallas
documents made available. Attendance book sent around. Introduction of
attendees.
ITEM 3 - March 16 agenda (X3J13/87-006) rearranged to bring forward points 8
and 9.
ITEM 4 - Sept 23-24 minutes (X3J13/86-025) sent out but had typos in names.
Corrections to other minutes will be noted in minutes of March 16-18
(X3J13/87-016)
ITEM 5 -Dec 10-12 minutes (X3J13/86-021) not yet available but should be
available by end of meeting.
ITEM 6
ISO ballot has been sent in, but the meeting is not planned until summer.
Anyone interested in joining the ISO working group is asked to contact Bob
Mathis. The size of the US delegation is planned to be about 6 people.
1:25pm ITEM 8 - Purposes of X3J13 Committee (X3J13/86-023 (revision of
X3J13/86-020))
1.
a. Guy Steele suggests changing "extensions" to "additional features".
Informal voice vote unanimously in favor.
b. Dave Moon concerned about phrase, "establishing normative practice".
Informal voice vote unanimously in favor of dropping phrase altogether.
"X3J13 is chartered to produce an American National Standard for Common
Lisp. It will codify existing practice and provide additional features to
facilitate portability of code among diverse implementations."
2.
a. Dave Matthews asks whether aesthetic criteria should exist at all.
Informal voice vote shows majority in favor of change in wording. Informal
voice vote unanimously in favor of Guy Steele's proposed wording change.
"The committee will begin with the language described in Common Lisp: The
Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current
de facto standard for Common Lisp. Whenever there is a proposal for the
standard to differ from Common Lisp: The Language, the committee shall
weigh both future costs of adopting (or not adopting) a change and the
costs of conversion of existing code. Aesthetic considerations shall
also be weighed, but as subordinate criteria."
2:30pm - Comments by John McCarthy. Comments will be put into
future article for Lisp Pointers.
2:35pm - Break
ITEM 9 - Reports from Task Group Chairpeople
2:50pm - Bob Balzer, Rich Berman (ISI) - Validation Suite
Rich Berman described the current status of the test suite design. Format has
been designed and 550 tests converted into that format.
Bob Balzer described how ISI could run the test suite against a particular
implementation and produce a report of the results. The process is currently in
the Ad-hoc Stage for evaluation. Later stages will result in a managed test
suite. The effort is estimated to take 3.5 person-years to produce 25,000
normalized cases.
Discussion identified concern over the final use of the test suite (ie., for
implementors or for users), and over the extent of the effort devoted to
resolution of ambiguity in the language standard showed up by test cases.
The topic will be continued on Wednesday.
4:25pm - Professor Ida - Lisp Activities in Japan (X3J13/87-007)
4:40pm - Gary Brown (DEC)
Gary Brown has received permission from DEC to hire a technical writer to do
the actual creation of the standard, with copyright held by ANSI. The response
of the committee was enthusiastic applause.
4:50pm - Larry Masinter (Xerox) - Cleanup Committee
Current status (X3J13/87-010) describes status as of March, 1987 rather than
May, 1987. Distribution of language suggestions and changes through computer
networks was discussed, but not resolved. The discussion will be continued
Wednesday.
5:10pm - Meeting adjourned.
Tuesday, March 17, 1987. Palo Alto meeting called to order.
9:05am - Dan Bobrow, Opening Remarks
Common Lisp Object System Specification
1. Programmer Interface Concepts (X3J13/87-002)
2. Functions in the Programmer Interface (X3J13/87-002)
3. Meta Object Protocol (X3J13/87-003)
4. Glossary (X3J13/87-008)
5. Corrections and Amendments (X3J13/87-009)
9:10am - David Moon, "Common Lisp, Object System"
10:35am - Break
11:00am - Gregor Kiczales, "Programming with Meta-Objects"
1:05pm - Lunch Break
2:45pm - Dan Bobrow, "Meta Object Protocol"
4:00pm - Break
4:25pm - Questions and Answers on previous presentations
The discussion resulted in the decision to vote Wednesday morning on the X3J13
position on the work done to date on the Common Lisp Object System
Specification.
5:50pm - Meeting adjourned.
Wednesday, March 18, 1987. Palo Alto meeting called to order.
9:05am - Peter Coffee presented the wording of a motion which reflected the
discussion of Tuesday afternoon. The X3J13 committee unanimously voice voted
to have this moved. A majority voice vote determined that the motion would be
presented as three separate items with X3J13 document references.
On a motion by Peter Coffee, and a second by Mark Wegman, the
following formal motion was passed by unanimous voice vote.
Resolved by the National Technical Committee for Standardization of
Lisp (X3J13):
(1) The committee believes that object-oriented programming
will be incorporated as part of a future Common Lisp standard;
(2) The committee believes that Chapters 1 and 2 of the Common Lisp
Object System (CLOS) specification (collectively, X3J13 document 87-002)
captures the essentials of the future standard object facility.
The committee also looks forward to a refined version of CLOS
Chapter 3 (X3J13/87-003) that will similarly reflect the
essentials of a standard meta-object facility;
(3) The committee encourages experimentation with the object
system reflected in CLOS Chapters 1-3.
SUBCOMMITTEE REPORTS
9:30am - Jon L. White - Iteration Subcommittee
JonL described the work done to date of the committee on identifying several
iteration paradymes, and will create a preliminary document for distribution.
9:35am - Kent Pitman - Macros; Errors and Conditions Subcommittee
Kent described the continuing work on xx (X3J13/xxx), and felt that the work
was beginning to converge. It is expected that the converged design will
be presented at the next meeting.
9:40am - Rich Berman - Validation and Conformance Subcommittee
Rich summarized the presentation which he gave on Monday.
9:45am - Gary Brown - Presentation of Standard Subcommittee
Gary reiterated that the standard will be controlled by ANSI rules. The actual
creation of the document will be done by a technical writer who will be hired
by DEC. The text editing system used for this document will be TEX.
An editorial subcommmittee has been formed. The current volunteers are
Pavel, Margolin, Slater, Fahlman, Weinreb, Pitman, Linden, Ennis, and Ida.
Gary suggested that a formal definition of some parts of Common Lisp would
be valuable. The response of the committee indicated that further discussion
of this issue was needed.
10:05am - Dan Bobrow - Objects Subcommittee
Dan thanked the committee for their feedback on the CLOS design.
10:07am - Dick Gabriel - Lisp 1/Lisp 2 Subcommittee
The topic has been temporarily quiescent, due to subcommittee members
being involved elsewhere.
10:10am - Steve Haflich - Compiler Specification Subcommittee.
A large amount of work has been done on a specification document. The subcommittee is intending to stop and look at
the more global issues of what their task encompasses and how they should
approach the problems.
10:20am - Bob Mathis - NEXT MEETING PLANNING
The consensus of the committee was to have a two full day meeting on
Tuesday (10am - 6pm) and Wednesday (9am - 4pm), June 30th and July 1st.
Subcommittees were encouraged to meet on Monday afternoon.
10:35am - Break
11:00am - Bob Mathis - FUTURE MEETING PLANNING
Susan Ennis has agreed to act as a clearinghouse for information on
possible meeting sites and times.
ll:00am - Larry Masinter - Cleanup Subcommittee
Bob Mathis will create a message to the Common Lisp mailing list describing the
standardization process. He will reiterate that the X3J13 committee is open,
but that it is only within X3J13 that the technical discussions will occur.
The discussion considered the ways in which the cleanup proposals would be
presented to the committee for final voting. When proposals are presented
in the future, Larry will identify those which are potentially controversial.
Proposals will be presented to the committee in advance of the meeting.
After a proposal has been accepted, the editorial committee will give
direction to the technical writer for incorporation into the standard.
12:00 noon - Final Meeting Adjournment
∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:42:25 PST
Date: 18 Mar 1987 13:43-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting documents
Subject: [MATHIS@ADA20.ISI.EDU: minutes first meeting]
Subject: [MATHIS@ADA20.ISI.EDU: document register]
Subject: [MATHIS@ADA20.ISI.EDU: Purposes document]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:43:03.MATHIS>
These messages were printed and distributed Wednesday morning at the meeting.
Begin forwarded messages
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:04:40-PST
Date: 17 Mar 1987 23:04-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: minutes first meeting
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:04:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
DRAFT Minutes X3J13 Committee Meeting
Dates: September 23-24, 1986
Location: CBEMA Headquarters, Washington, DC
Chair: Bob Mathis (acting)
Secretary: Steve Haflich (acting)
Hour of opening: September 23, 1986, 9:00 AM
Hour of adjournment: September 24, 1986, 3:00 PM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None (this was first meeting)
Register of Documents: Attached
Motions seconded and not withdrawn:
Future meeting schedule:
The next meeting is scheduled for Decmeber 10-12, 1986, in
Dallas, TX. Ellen Waldrum will make the arrangements.
List of action items assigned to committee members:
Mathis will contact DEC Press about using the Steele book as a
basis for the standard
The meeting was called to order at 10:00 AM, September 23, 1986.
The agenda, X3J13/86-001, was approved without objection.
Catherine Kachuric, Director of the X3 Secretariat presented a
tutorial on the organization and operation of X3. Most of the
details are codified in the X3/SD-2 operating document which was
distributed at the meeting.
Mathis led a discussion of meeting procedures:
1. by consensus it was decided there will be no smoking in
X3J13 meeting rooms;
2. each meeting will focus on one or more technical issues
with prepared presentations, it is necessary that the
membership be well prepared technically in advance of
meetings so that final discussions and voting can be
facilitated during scarce meeting time;
3. Gabriel will set up a new mailing list which will function
as a subset of the existing COMMON-LISP@SAIL.STANFORD.EDU,
and therefore nothing should be sent to both lists. Also,
anything with a time limit for action should be sent to
X3J13, not COMMON-LISP, as not all members will read the
latter in a timely fashion. Addresses are:
X3J13@SAIL.STANFORD.EDU
X3J13-REQUEST@SAIL.STANFORD.EDU
RPG@SAIL.STANFORD.EDU
4. Mathis can be reached at MATHIS@B.ISI.EDU. Since only a
few members lack internet access, the committee will
consider using electronic mail for discussion. Mathis will
attempt to arrange network access for members in need.
All written X3 subcommittee communications are distributed to
everybody and are filed as part of the official records. There
was discussion whether this would apply to electronic mail to
x3j13@Stanford. Some people feel that network comments are made
informally and are similar to oral communications; therefore,
they should not be available as a written record. There was a
conflicting desire that the archives be publically available
(e.g. via FTP) since this has proven useful with
COMMON-LISP@STANFORD. It was provisionally agreed that the
archives would be maintained, but for now they would not be
publically accessible.
There was further discussion of how to bypass one of the
shortcomings of electronic communication -- the volume of the
archive makes it a poor reference source and decisions can get
lost. Therefore, it was oproposed that when discussion on a point
dies down there should be a summarization of discussion placed in
a small, more readable ledger and this document would be recorded
and distributed by X3J13.
Mathis requested a committee to further consider the use of
network communication: Mathis, Pitman, Fahlman, Rosenking, and
Haflich.
Mathis led a discussion of the project proposal (subsequently
given the number X3J13/SD-2.
The title is "Common Lisp" rather than "Lisp" although this could
be changed with little effort. The scope of the committee is one
of the items that will have to be decised. There was general
agreement that we are standardizing Common Lisp, not all Lisp for
all time. Gabriel informed the meeting that McCarthy objects to
our using plain "Lisp." It is intended that X3J13 will subsume
the less formal technical committee formed after the December
1985 Boston meeting.
Several parties were interested in the relationship with Digital
Press over rights to use the Steele book. Considerable discussion
occurred with the eventual result that Mathis would work directly
with Digital Press to make appropriate arrangements.
After a lunch recess, the meeting reconvened at 2:30 PM.
Dan Bobrow made an introductory presentation on Common Loops.
[The preliminary document for this presentation was 86-004 and
the slides from it were distributed as 86-006.] Discussion of
Common loops followed, particularly regarding the nature of a
specification and the best process for arriving at one. There
will be a small meeting at OOPSLA on the current proposal and a
new draft will follow.
Mathis reported that Mary van Deusen has volunteered to produce
an unedited Lisp newsletter in the same manner that she produced
the original Ada newsletter. It was also noted that Gabriel and
Steele will also be editing a professional refereed quarterly for
Kliewer. Both publications felt there was no conflict.
There was some technical discusison of removing function-value
cell separation from Common Lisp. Discussion was started
explicitly to serve a s a trial vehicle to focus on the extent to
which the committee would be willing to make changes that would
disrupt the installed base. This discussion will be continued at
future meetings.
A subcommittee, chaired by Ennis, was formed to develop a draft
document for the proposed scope and purposes of X3J13. They met
over dinner and during the evening. Their draft [86-005] was
presented the next morning.
The meeting was recessed on September 23, 1986 at 5:15 PM.
The meeting was resumed on September 24, 1986 at 9:00 AM.
Steele led a discussion of his two documents relating to SD-1
[Common Lisp: The Language] which were first distributed at the
December 1985 Common Lisp community meeting [86-002 and 86-003].
The intention is that once a version of 86-002 is approved, all
references to SD-1 will mean the Steele book "as corrected."
There was considerable discussion on the various topics, but no
specific issues were resolved at the meeting.
After a lunch recess, the meeting reconvened at 1:00 PM.
Mathis led a discussion of a potential meeting schedule. Several
offers were made including MCC Austin, MIT Boston, and TI Dallas.
After a discussion of optimizing meeting location, timing,
length, etc., it was decisded to meet in Dallas, December 10-12.
There was also sentiment expressed for the next meeting to be in
Palo Alto and the one after that in Boston.
Mathis asked the following to serve as an agenda committee for
the next meeting: Mathis, Fahlman, Gabriel, Purdue, Ennis,
Steele, and Scherlis. Furthermore, these items were suggested as
natural for the next agenda:
-- studying the possibility of merging symbol function cells
in Common Lisp with value cells (like Scheme),
-- Pitman will presnet the error system proposal,
-- further consideration of the current scoping and
declaration issues (the intention is to devise a proposal
over the network to be disteributed before the meeting),
-- the ongoing negotiations with ISO.
The meeting was adjourned on September 24, 1986 at 3:00 PM.
Respectfully Submitted,
Steve Haflich and Bob Mathis
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:10:04-PST
Date: 17 Mar 1987 23:10-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: document register
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:10:01.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
Standing Documents (date of latest revision)
SD-01 Common Lisp: The Language, Guy L. Steele Jr., Digital
Press, 1984.
SD-02 Common Lisp Project Prosal to SPARC (86.02.18)
SD-03 Current Membership List of X3J13 (in preparation)
SD-04 Meeting Schedule (87.02.10)
SD-05 Purposes of X3J13 Committee (87.03.16)
This year's Documents
87-000 Document Register for 1987 (87.03.17)
87-001 Document Register for 1986 (87.02.10)
87-002 Objects Chapter 1 & 2
87-003 Objects Chapter 3
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
87-006 Cover letter dated 87.02.10 which included 86-017,
86-018, 86-019, 86-020R, 86-023, 86-024, 87-000, 87-001,
87-004, 87-005, SD-04.
87-007 A Progress Report on the Common Lisp Related Activities
in Japan by Masayuki Ida.
87-008 Common Lisp Object System Specification Glossary
87-009 Common Lisp Object System Specification Corrections and
Amendments to the Document
87-010 Cleanup Committee Report
87-011 "Encapsulation and Inheritance in Object-Oriented
Programming Languages" by Alan Snyder, OOPSLA, 1986.
87-012 Slides from David Moon's presentation 87.03.17
87-013 Slides from Gregor Kiczales's presentation 87.03.17
87-014 Slides from Danny Bobrow's presentation 87.03.17
87-015 Further reactions to 86-019
87-016 Draft Minutes Palo Alto meeting 87.03.16-18
87-017 Cover letter dated 87.03.29 which included
87-018
87-019
Next year's Documents
88-000 Document Register for 1988
88-001 Document Register for 1987
88-002
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:14:39-PST
Date: 17 Mar 1987 23:14-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Purposes document
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:14:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
X3J13/SD-05 Purposes of X3J13 Committee (87.03.16)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice and provide
additional features to facilitate portability of code among
diverse implementations.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic considerations shall also be weighed,
but as subordinate criteria.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
--------------------
End forwarded messages
∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:45:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA27326@EDDIE.MIT.EDU>; Fri, 20 Mar 87 16:45:27 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA00379; Fri, 20 Mar 87 15:42:59 EST
Message-Id: <8703202042.AA00379@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 20 Mar 87 14:41:51 EST
Subject: Windows and Graphics Subcommittee
To: x3j13@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 20 Mar 87 14:41:51 EST
I would like to make known that there is a mailing list for the
windows and graphics subgroup. To subscribe you can send mail
to me as dougr@eddie.mit.edu. The mailing list is
x3j13-windows@primerd.prime.com@eddie.mit.edu
Cheers,
Doug Rand
∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:29:08 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05051; Mon, 23 Mar 87 11:30:48 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703231930.AA05051@vaxa.isi.edu>
Date: 23 Mar 1987 1130-PST (Monday)
To: X3J13@SAIL
Cc:
Subject: Gary Brown...
I tried to send you mail at brown%bizet.DEC@decwrl.dec.com, but no luck, says
host not known. You got another address??
RB
∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp
Dear Bob Mathis,
Please suggest your idea on the contents of this mail.
Thank you.
Masayuki
--------------------------------------------------------
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
the whole contents to common-lisp@sail.stanford to get
reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
on the week of May 11th.
4) We are ready to send a person to the next meeting
to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
be transfered to WG members as quick as possible.
(several of them have E-mail links to ida.)
We will try to discuss on the issue by E-mails as possible as we can.
(we have no ethernet-like link to USA, so we cannot reply immediately.)
we finished the first draft of the english version.
It was mainly translated by the person of Nippon Symbolics.
(Thanks Mr.Shiota.)
The size is 12 pages long in letter sized papers.
We will revise up and send it.
Masayuki Ida
∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 22:53:25 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Mon, 20 Apr 87 21:53:46 pst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Mon, 20 Apr 87 23:52:41 mst
Received: by hpfcdcm.HP.COM; Mon, 20 Apr 87 22:53:41 mst
Date: Mon, 20 Apr 87 22:53:41 mst
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Return-Path: <dcm@hpfcdcm>
Message-Id: <8704210553.AA03000@hpfcdcm.HP.COM>
To: +cl/x3j13@hplabs.HP.COM, x3j13@sail.stanford.edu
Subject: Fall X3J13 meeting
It probably seems a little early to start thinking about our fall meeting,
but I thought I would take an informal survey to help make the necessary
arrangements so we can confirm them at the summer meeting.
At the last X3J13 meeting, Susan Ennis volunteered to coordinate the
meeting schedule and I volunteered to host the fall meeting of X3J13
in colorful Colorado. We recently talked about the schedule for the
fall meeting and there seem to be a number of conferences that
time of year. We would like to pick a time convenient to as many
members as possible so I would like to conduct a survey.
Three months after the next meeting in late June would be late September
so I would nominally suggest September 28-30. Please fill out the
following table of available dates, listing the conflict if you believe
that others on the committee may have it also, such as OOPSLA.
Dates: MTWTF(y/n) Conflict?
------------- ----- ---------------------
Sep 21-Sep 25
Sep 28-Oct 2 yyyyy Example
Oct 5-Oct 9
Oct 12-Oct 16
Oct 19-Oct 23
Hopefully this range of dates will be sufficient for choosing 3 days.
I'll use this information to make preliminary arrangements and have a
proposal ready at the next meeting. Please return this by May 29.
Thanks,
Dave Matthews
dcm%hpfclp@hplabs.hp.com
∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:21:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195935; Tue 21-Apr-87 07:24:34 EDT
Date: Tue, 21 Apr 87 07:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: On the Kanji feature of Common Lisp
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8704200733.AA14916@tansei.u-tokyo.junet>
Message-ID: <870421072404.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
Professor Ida:
I believe it doesn't do it justice to describe this extension as a
"kanji extension". I have not yet seen an English translation of the
proposal, but from what I have seen of it, it appears to address much
wider concerns. I believe the concerns are quite relevant to any
implementation which deals with extended character-sets, or even which
try to make use of Common-Lisp's unfortunate "font" features.
From what I've been able to make of the proposal, it seems you are
on the right track, and I eagerly await your proposal.
∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 01:06:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13110; 23 Apr 87 4:02 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab04744; 23 Apr 87 3:54 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA27855; Thu, 23 Apr 87 16:04:19 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA04391; Thu, 23 Apr 87 15:55:22+0900
Date: Thu, 23 Apr 87 15:55:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704230655.AA04391@tansei.u-tokyo.junet>
To: RWK@SCRC-YUKON.ARPA, ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the character-set extension of Common Lisp
>Date: Tue, 21 Apr 87 07:24 EDT
>From: "Robert W. Kerns" <RWK@scrc-yukon.arpa>
>Subject: On the Kanji feature of Common Lisp
>To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
> Date: Mon, 20 Apr 87 16:33:09+0900
> From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
> On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
> Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>
>Professor Ida:
>
>I believe it doesn't do it justice to describe this extension as a
>"kanji extension". I have not yet seen an English translation of the
>proposal, but from what I have seen of it, it appears to address much
>wider concerns. I believe the concerns are quite relevant to any
>implementation which deals with extended character-sets, or even which
>try to make use of Common-Lisp's unfortunate "font" features.
>
>>From what I've been able to make of the proposal, it seems you are
>on the right track, and I eagerly await your proposal.
>
>
Dear RWK,
you are right. I should have not described our conclusion on the extended
character-set manipulation as "kanji extension".
Though I myself told the WG on the Apr 17 meeting to update our document
to use the word "multi-byte character"
instead of "japanese character" or "kanji",
I myself missed to refer it as a "kanji" extension in my last mail.
Thank you
Masayuki Ida
∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 04:36:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 15 May 87 06:35:50-CDT
Date: Fri, 15 May 87 06:34 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Next Meeting
To: X3J13%sail.stanford.edu@MCC.COM
cc: Loeffler@MCC.COM
Message-ID: <870515063459.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
I have not seen any activity on this mailing list since the 23th of
April. What are the arrangements for the next meeting?
-- David D. Loeffler
∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:03:19 PDT
Date: 31 May 1987 09:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: RWS@ZERMATT.LCS.MIT.EDU
Message-ID: <[ADA20.ISI.EDU]31-May-87 09:02:47.MATHIS>
A few words about the upcoming X3J13 meeting:
The meeting is being hosted by Goldhill Computers. Maria Santos
is making the arrangements. Their phone number is (617)
492-2071. They are reserving some rooms at the Cambridge Marriott
at a rate of $115 (plus tax) per night (insead of the more usual
$135). There will be some fee for refreshments and maybe a lunch.
I don't know what it will be, but at the last two meetings we
paid $25 or $50. The meeting will be on Tuesday June 30 and
Wednesday July 1. We will be meeting from about 9am to 5pm each
day. There may be some subcommittee meetings on Monday. They are
hoping to arrange some meeting rooms at MIT, but I don't know the
specifics yet. Hope you can all make it.
I was thinking about the following agenda:
Tuesday morning -- clean-up committee
Tuesday afternoon -- X windows presentation, Japanese
characters presentation, administrative work of committee,
reports from various subcommittees and liaisons
Wednesday morning -- continuation of subcommittee reports
and other business, clean-up committee
Wednesday afternoon -- clean-up committee
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
The X windows presentation will be by Robert Scheifler. We are
not looking at this for incorporation into the Common Lisp
standard, but as an important and relevant related application.
CLX is a proposed interface to the X Version 11 Window System
Protocol. It is intended as fairly low-level veneer, to hide
mundane details such as data encodings, network I/O, and even the
existance of an explicit inter-process communication channel.
The intent is to provide direct access to features of the
protocol, but with an effective Lisp orientation, and with
consideration given to convenience of use. A goal was to permit
efficient implementations on both conventional and Lisp-specific
architectures, and to provide reasonable semantics in both
single-process and multi-process environments. The expectation
and desire is that this X-specific interface will be wrapped by
more generic and higher-level windowing and graphics interfaces,
suitable for general application programming. However, we did
not wish to preclude an X-specific, object-oriented system built
directly on this interface. A public implementation of this
interface is underway, to serve as a mechanism for evaluating the
interface.
I am sending five relatively long messages which I recieved from
Scheifler which give the protocol and the Lisp code.
The Japanese characters proposal was sent to the general Common
Lisp mailing list. I am retransmitting it for your reference.
The cleanup committee has been hard at work and they will shortly
be sending their documents. So read what I'm sending now and save
it some place because more is coming.
-- Bob
∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:47 PDT
Return-Path: <@USC-ECLB.ARPA,@SAIL.STANFORD.EDU,@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal
-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]
@heading[1. Hierarcy of characters and strings]
Let the value of char-code-limit be large enough to include all
characters.
char > string-char >= internal-string-char > standard-char
string >= internal-thin-string > simple-internal-thin-string
simple-string >= simple-internal-thin-string
string = (or internal-thin-string (vector string-char))
Type internal-thin-string and (vector string-char) are
disjoint or identical.
simple-string = (or simple-internal-thin-string
(simple-array string-char (*)))
Type simple-internal-thin-string and (simple-array
string-char (*)) are disjoint or identical.
notes: A > B means B is a subtype of A,
A >= B means B is a subtype of A or B is equal to A.
@Heading[2. Print width]
Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.
@Heading[3. Functions]
Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.
Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.
Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]
The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp. This report is the result of many
discussions of many proposals. Of course, this report doesn't satisfy
all proposals, but it is very close.
In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.
Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures. If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.
Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).
@Heading[2. Additional features for embedding multi-byte characters.]
This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.
There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data
but not as variables or function names.
It is necessary for programming languages like Lisp that use symbolic data
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and
symbols, and it must be possible to store both kinds of characters in them.
Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes. Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.
Thus, the basic design principles for embedding multi-byte character to Common Lisp are:
@Begin[Itemize]
Multi-byte character should be treated like single-byte character, that is,
a multi-byte character is one character object.
@End[Itemize]
@Begin[Itemize]
A program which was coded without explicit attention for multi-byte character should
handle multi-byte character data as is.
@End[Itemize]
These principles provide sufficient functionality, but we can't ignore
efficiency. So we considered the next principle:
@Begin[Itemize]
The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.
@End[Itemize]
This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise. We think that following methods will satisfy both of these
requirements.
@Heading[3. Common parts which we implement.]
This chapter describes the implementation of multiple character sets in Common Lisp.
To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.
We consider the following implementation methods.
@Begin[Itemize]
Add multi-byte characters by setting the variable char-code-limit to a large number.
@End[Itemize]
In this case, the single-byte character set and the multi-byte character
set must be ordered into a single sequence of character codes. This means multi-byte
character set must not overlap with the single-byte character set. This method could
be satisfied within most implementations with ease.
If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte
character will also work for multi-byte character without any change.
This implementation method has problems with efficiency.
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected. A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names. If we can solve the problem
for strings, we can solve other problems, so we will start by considering only strings.
To avoid this memory utilization problem, it is possible to optimize and
make single-byte character strings by packing internally. In other words,
to have two kinds of data types and not show it to user. There is only one type of
data from the viewpoint of users, which means that every function which uses strings
will continue to work as defined.
This can be implemented in almost everywhere without so many costs. The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string. To work according to the definition, the implementation
must unpack the original packed string. This presents an implementation inefficiency which
the user may find undesirable.
One solution would be to
@Begin[Itemize]
Generate errors for operations that try to use multi-byte characters into
single-byte string and presenting two string datatypes to users.
@End[Itemize]
We propose this latter implementation. Common lisp should have 2 string
types to treat multi-byte characters efficiently. The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero. The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0]. The predicate which tests for this type of character is
@B[ε1internal-thin-char-pε0].
The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0].
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
may arise where both sets describe the same character-set.
This is equivalent to the type of system that has only one type of character from the
viewpoint of the user as discussed in the previous chapter. This proposal permits both
kinds of implementations.
@newpage
@Begin[Verbatim]
character
|
string-char
|
internal-thin-char
|
standard-char
@Center[Fig-1.a Structure of character type]
string
|
-----------------------------------
| | |
| simple-string |
| | |
internal-thin-string | (vector string-char)
| | |
-----------------------------------
| |
| |
simple-internal-thin-string (simple-array string-char (*))
@Center[Fig-1.b Structure of string type]
@End[Verbatim]
To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format. This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].
Next we must discuss character input. The proposal does not discuss what is stored
in files, nor what happens between the Lispimplementation and a terminal.
Each system will implement this in itsown way. Instead, let us discuss the data
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0]
is the safest possible course. Since a symbol's p-name string should not be modified,
it can be optimized.
This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs. When its value is @B[ε1internal-thin-stringε0], the system
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]
In this section, we list proposed modifications to CLtL. Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables. For other chapters we specify only additional
and modifying parts. Those portions which are not mentioned are
unchanged.
@b(2 Data Types)
@b(2.5.2 Strings)
@begin(equation)
"a string is a specialized vector .... type string-char"
↓
"a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
@b(2.15 Overlap,Inclusion and Disjointness of Types)
a description of type string-char is changed to :
Type standard-char is a subtype of @B[internal-thin-char].
@B[internal-thin-char] is a subtype of string-char. string-char is a
subtype of character.
and add the following :
Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means
(vector internal-thin-char).
a description of type string is changed to :
Type string is a subtype of vector because string means (or
(vector string-char) internal-thin-string). Type (vector
string-char) and @B[internal-thin-string] are disjoint or equality.
a description of type simple-vector,simple-string ... is changed to :
Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
simple-array because each one means (simple-array t (*)),
(or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
(simple-array bit (*)).
and add following :
Type simple-internal-thin-string means (simple-array
internal-thin-char (*)) and is a subtype of @B[internal-thin-string].
Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
equality.
@b(4 Type Specifiers)
@b(4.1 Type Specifier Symbols)
add followings to system defined type specifiers :
simple-internal-thin-string
internal-thin-string
internal-thin-char
@b(4.5 Type Specifiers That Specialize)
"The specialized types (vector string-char) ... data types."
↓
"The specialized types (vector internal-thin-char), (vector
string-char) and (vector bit) are so useful that they have the
special names string and bit-vector. Every implementation of Common
Lisp must provide distinct representation for string and bit-vector
as distinct specialized data types."
@begin(equation)
@b(13 Characters)
@b(13.1 Character Attributes)
char-code-limit@>[constant]
char-font-limit@>[constant]
char-bits-limit@>[constant]
@b(13.2 Predicates on Characters)
standard-char-p char@>[constant]
graphic-char-p char@>[constant]
@begin(quotation)
a description "graphic characters of font 0 are all of the same width when printed" in
the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
width when printed".
@end(quotation)
string-char-p char @>[function]
internal-thin-char-p char@>[function]
@begin(quotation)
this function must be added.
the argument char must be a character object. internal-thin-char-p
is true if char can be stored into a internal-thin-string, and
otherwise is false.
@end(quotation)
alpha-char-p char@>[function]
upper-case-p char@>[function]
lower-case-p char@>[function]
both-case-p char@>[function]
"If a character is either ... alphabetic."
↓
"If a character is either uppercase or lowercase, it is necessarily character
that alpha-char-p returns true."
digit-char-p char &optional (radix 10)@>[function]
alphanumericp char@>[function]
char= character &rest more-characters@>[function]
char/= character &rest more-characters@>[function]
char< character &rest more-characters@>[function]
char> character &rest more-characters@>[function]
char<= character &rest more-characters@>[function]
char>= character &rest more-characters@>[function]
char-equal character &rest more-characters@>[function]
char-not-equal character &rest more-characters@>[function]
char-lessp character &rest more-characters@>[function]
char-greaterp character &rest more-characters@>[function]
char-not-greaterp character &rest more-characters@>[function]
char-not-lessp character &rest more-characters@>[function]
@b(13.3 Character Construction and Selection)
char-code char@>[function]
char-bits char@>[function]
char-font char@>[function]
code-char char &optional (bits 0) (font 0)@>[function]
make-char char &optional (bits 0) (font 0)@>[function]
@b(13.4 Character Conversion)
character char@>[function]
char-upcase char@>[function]
char-downcase char@>[function]
digit-char weight &optional (radix 10) (font 0)@>[function]
char-int char@>[function]
int-char char@>[function]
char-name char@>[function]
name-char char@>[function]
@b(13.5 Character control-bit functions)
char-control-bit@>[constant]
char-meta-bit@>[constant]
char-super-bit@>[constant]
char-hyper-bit@>[constant]
char-bit char name@>[function]
set-char-bit char name newvalue@>[function]
@b(14 Sequence)
@b(14.1 Simple sequence functions)
elt sequence index@>[Function]
subseq sequence start &optional end@>[Function]
copy-seq sequence@>[Function]
length sequence@>[Function]
reverse sequence@>[Function]
nreverse sequence@>[Function]
make-sequence type size &key :initial-element@>[Function]
@b(14.2 Sequence connection)
concatenate result-type &rest sequences@>[Function]
map result-type function sequence &rest more-sequences@>[Function]
some predicate sequence &rest more-sequences@>[Function]
every predicate sequence &rest more-sequences@>[Function]
notany predicate sequence &rest more-sequences@>[Function]
notevery predicate sequence &rest more-sequences@>[Function]
reduce function sequence@>[Function]
&key :from-end :start :end :initial-value
@b(14.3 Sequence correction)
fill sequence item &key :start :end@>[Function]
replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]
remove item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
delete item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
delete-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
subsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
subsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
subsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
nsubsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
@b(14.4 Search)
find item sequence @>[Function]
&key :from-end :test :test-not
:start :end :key
find-if test sequence @>[Function]
&key :from-end :start :end :key
find-if-not test sequence>[Function]
&key :from-end :start :end :key
position item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
position-if test sequence@>[Function]
&key :from-end :start :end :key
position-if-not test sequence@>[Function]
&key :from-end :start :end :key
count item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
count-if item sequence@>[Function]
&key :from-end :start :end :key
count-if-not item sequence@>[Function]
&key :from-end :start :end :key
mismatch sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
search sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
@b(14.5 Sort,merge)
sort sequence predicate &key :key@>[Function]
stable-sort sequence predicate &key :key@>[Function]
merge result-type sequence1 sequence2 predicate &key :key@>[Function]
@b(18 Strings)
"the type string is identical ... (array string-char (*))."
↓
"the type string is identical to the type
(or (vector internal-thin-char) (vector string-char)),
which in turn is the same as (or (array internal-thin-char (*))
(array string-char (*)))."
@b(18.3 String Construction and Manipulation)
make-string size &key :initial-element@>[function]
@begin(quotation)
add following :
To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)
@b(22 Input/Output)
@b(22.2 Input Functions)
@b(22.2.1 Output to Character Stream)
add following :
*read-default-string-type*@>[variables]
@begin(quotation)
The value is string or internal-thin-string. This determines string that the function
read takes whether type string or internal-thin-string.
@end(quotation)
@b(22.3 Output Functions)
@b(22.3.1 Output from Character Stream)
@begin(quotation)
add following :
@end(quotation)
write-width object@>[function]
&key :unit-type :stream :escape :radix :base
:circle :pretty :label :length :case :gensym :array
@begin(quotation)
This function returns the printed width as the value of the unit
specified by :unit-type when then printed representation of
object is written to the output stream specified by :stream. It
returns nil when object includes control characters
(#\Newline,#\Tab etc). The default of :unit-type is byte. The
value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]
In addition to the modification of CLtL, here are some suggestions for systems
including Japanese characters.
1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.
2). About function that are specific to Japanese and no at all related
to multi-byte processing.
Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry
Standard.
@begin(equation)
@b(13. Characters)
@b(13.1. Character Attributes)
char-code-limit char @>[Function]
@begin(quotation)
The value of char-code-limit should be large enough to include Japanese characters,
e.g. 65536.
@end(quotation)
@b(13.2. Predicates on Characters)
standard-char-p char @>[Function]
@begin(quotation)
Return nil for all Japanese characters.
@end(quotation)
graphic-char-p char @>[Function]
@begin(quotation)
Return t for Japanese characters.
@end(quotation)
internal-thin-char-p char @>[Function]
@begin(quotation)
The result depends on each implementation that whether the Japanese character is in
internal-thin-string or not.
@end(quotation)
alpha-char-p char @>[Function]
@begin(quotation)
Return nil for all character except alphabets in Japanese character. It depends on
each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)
@newpage
jis-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. jis-char-p is true if the
argument is included in JIS C-6226, and otherwise false.
@end(quotation)
japanese-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. japanese-char-p is true if the
argument is a Japanese character and is otherwise false. All characters that satisfy
jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
kanji-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object. kanji-char-p is true if the
argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
the kanji numeric zero or the same as above symbol for a total of 6356 characters
that also satisfy jis-char-p.
@end(quotation)
hiragana-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object.
hiragana-char-p is true if the argument is one of the 83
hiragana characters in JIS C6226(3.1.4), the hiragana repeat
symbol, or dakuten for a total of 85 characters that also
satisfy jis-char-p.
@end(quotation)
katakana-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object.
katakana-char-p is true if the argument is one of the 86
hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
katakana-repeat symbol, or katakana-dakuten for a total of 89
characters that also satisfy jis-char-p.
@end(quotation)
kana-char-p char@>[Function]
@begin(quotation)
equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)
upper-case-p char@>[Function]
lower-case-p char@>[Function]
both-case-p char@>[Function]
@begin(quotation)
These are nil if the argument does not satisfy alpha-char-p.
Japanese characters which satisfy alpha-char-p should be treated
as normal alphabetic characters.
@end(quotation)
@newpage
digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
digit-char-p is nil if the argument is a Japanese character.
@end(quotation)
alphanumericp char@>[Function]
@begin(quotation)
equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)
char= character &rest more-characters@>[Function]
char/= character &rest more-characters@>[Function]
char< character &rest more-characters@>[Function]
char> character &rest more-characters@>[Function]
char<= character &rest more-characters@>[Function]
char>= character &rest more-characters@>[Function]
@begin(quotation)
The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)
@b(13.4 character Conversions)
char-upcase char@>[Function]
char-downcast char@>[Function]
@begin(quotation)
These return the argument if the argument does not satisfy
alpha-char-p. It depends on the implementation whether these
work on the alphabets included in JIS or not. But it should be
consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:13:44 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 1 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095642.5.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
;; Draft Version 3.1 (corresponds to Alpha Update protocol document)
;; Author:
;; Robert W. Scheifler
;; Laboratory for Computer Science
;; 545 Technology Square, Room 418
;; Cambridge, MA 02139
;; rws@zermatt.lcs.mit.edu
;; Contributors:
;; Dan Cerys, Texas Instruments
;; Scott Fahlman, CMU
;; Kerry Kimbrough, Texas Instruments
;; Chris Lindblad, MIT
;; Rob MacLachlan, CMU
;; Mike McMahon, Symbolics
;; David Moon, Symbolics
;; LaMott Oren, Texas Instruments
;; Daniel Weinreb, Symbolics
;; John Wroclawski, MIT
;; Richard Zippel, Symbolics
;; Note: all of the following is in the package XLIB.
;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious. We have no intention of writing yet
;; another moby document for this interface.
;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ... Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.
;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids. This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions. Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.
;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:
(defun make-<mumble> (display resource-id)
;; This function should almost never be called by applications, except in handling
;; events. To minimize consing in some implementations, this may use a cache in
;; the display. Make-gcontext creates with :cache-p nil. Make-font creates with
;; cache-p true.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
;; The following functions are provided by color objects:
;; The intention is that IHS and YIQ and CYM interfaces will also exist. Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
;; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status ()
'(member :success :already-grabbed :frozen :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
;; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gcontext-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct bitmap-format
(unit <unspec> :type (member 8 16 32))
(pad <unspec> :type (member 8 16 32))
(lsb-first-p <unspec> :type boolean))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(pad <unspec> :type (member 8 16 32)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(default-char <unspec> :type integer)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; and protocol are not constrained, and will likely be very system dependent. The
;; default protocol is system specific. Authorization, if any, is assumed to come
;; from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
;; Values are integers.
(declare (type display display)
(values major minor)))
(defun display-vendor (display)
;; Values are string and integer
(declare (type display display)
(values name release)))
(defun display-image-lsb-first-p (display)
(declare (type display display)
(values boolean)))
(defun display-bitmap-formap (display)
(declare (type display display)
(values bitmap-format)))
(defun display-pixmap-formats (display)
(declare (type display display)
(values (list pixmap-formats))))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
;; All errors (synchronous and asynchronous) are processed by calling an error
;; handler in the display. If handler is a sequence it is expected to contain
;; handler functions specific to each error; the error code is used to index the
;; sequence, fetching the appropriate handler. Any results returned by the handler
;; are ignored; it is assumed the handler either takes care of the error
;; completely, or else signals. For all core errors, the keyword/value argument
;; pairs are:
;; :display display
;; :error-key error-key
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
;; :window errors another pair is:
;; :resource-id integer
;; For :atom errors, another pair is:
;; :atom-id integer
;; For :value errors, another pair is:
;; :value integer
(declare (type display display)
(type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
handler)))
(defmacro define-condition (name base &body items)
;; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(defun default-error-handler (&rest key-vals)
;; The default display-error-handler.
;; It signals the conditions listed below.
)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gcontext-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
;; This macro is for use in a multi-process environment. It provides exclusive
;; access to the local display object for multiple request generation. It need not
;; provide immediate exclusive access for replies; that is, if another process is
;; waiting for a reply (while not in a with-display), then synchronization need not
;; (but can) occur immediately. Except where noted, all routines effectively
;; contain an implicit with-display where needed, so that correct synchronization
;; is always provided at the interface level on a per-call basis. Nested uses of
;; this macro will work correctly. This macro does not prevent concurrent event
;; processing; see with-event-queue.
)
(defun display-force-output (display)
;; Output is normally buffered; this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
;; Forces output, then causes a round-trip to ensure that all possible errors and
;; events have been received.
(declare (type display display)))
(defun display-after-function (display)
;; setf'able
;; If defined, called after every protocol request is generated, even those inside
;; explicit with-display's, but never called from inside the after-function itself.
;; The function is called inside the effective with-display for the associated
;; request. Default value is nil. Can be set, for example, to
;; #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border gravity bit-gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in the
;; request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null win-gravity) gravity)
(type (or null bit-gravity) bit-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun window-class (window)
(declare (type window window)
(values (member :input-output :input-only))))
(defun window-visual (window)
(declare (type window window)
(values integer)))
(defsetf window-background (window) (background)
(declare (type window window)
(type (or (member :none :parent-relative) integer pixmap) background)))
(defsetf window-border (window) (border)
(declare (type window window)
(type (or (member :copy) integer pixmap) border)))
(defun window-gravity (window)
;; setf'able
(declare (type window window)
(values win-gravity)))
(defun window-bit-gravity (window)
;; setf'able
(declare (type window window)
(values bit-gravity)))
(defun window-backing-store (window)
;; setf'able
(declare (type window window)
(values (member :not-useful :when-mapped :always))))
(defun window-backing-planes (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-backing-pixel (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-save-under (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-event-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-do-not-propagate-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-override-redirect (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-colormap (window)
(declare (type window window)
(values (or null colormap))))
(defsetf window-colormap (window) (colormap)
(declare (type window window)
(type (or (member :copy) colormap) colormap)))
(defsetf window-cursor (window) (cursor)
(declare (type window window)
(type (or (member :none) cursor) cursor)))
(defun window-colormap-installed-p (window)
(declare (type window window)
(values boolean)))
(defun window-all-event-masks (window)
(declare (type window window)
(values integer)))
(defun window-map-state (window)
(declare (type window window)
(values (member :unmapped :unviewable :viewable))))
(defsetf drawable-x (window) (x)
(declare (type window window)
(type integer x)))
(defsetf drawable-y (window) (y)
(declare (type window window)
(type integer y)))
(defsetf drawable-width (window) (width)
;; Inside width, excluding border.
(declare (type window window)
(type integer width)))
(defsetf drawable-height (window) (height)
;; Inside height, excluding border.
(declare (type window window)
(type integer height)))
(defsetf drawable-border-width (window) (border-width)
(declare (type window window)
(type integer border-width)))
(defsetf window-priority (window &optional sibling) (mode)
;; A bit strange, but retains setf form.
(declare (type window window)
(type (or null window) sibling)
(type (member :above :below :top-if :bottom-if :opposite) mode)))
(defmacro with-state ((drawable) &body body)
;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
;; ConfigureWindow. The body is not surrounded by a with-display. Within the
;; indefinite scope of the body, on a per-process basis in a multi-process
;; environment, the first call within an Accessor Group on the specified drawable
;; (the object, not just the variable) causes the complete results of the protocol
;; request to be retained, and returned in any subsequent accessor calls. Calls
;; within a Setf Group are delayed, and executed in a single request on exit from
;; the body. In addition, if a call on a function within an Accessor Group follows
;; a call on a function in the corresponding Setf Group, then all delayed setfs for
;; that group are executed, any retained accessor information for that group is
;; discarded, the corresponding protocol request is (re)issued, and the results are
;; (again) retained, and returned in any subsequent accessor calls.
;; Accessor Group A (for GetWindowAttributes):
;; window-visual, window-class, window-gravity, window-bit-gravity,
;; window-backing-store, window-backing-planes, window-backing-pixel,
;; window-save-under, window-colormap, window-colormap-installed-p,
;; window-map-state, window-all-event-masks, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect
;; Setf Group A (for ChangeWindowAttributes):
;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
;; window-backing-pixel, window-save-under, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
;; window-cursor
;; Accessor Group G (for GetGeometry):
;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
;; drawable-height, drawable-border-width
;; Setf Group G (for ConfigureWindow):
;; drawable-x, drawable-y, drawable-width, drawable-height, drawable-border-width,
;; window-priority
)
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun add-to-save-set (window)
(declare (type window window)))
(defun remove-from-save-set (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun circulate-window-up (window)
(declare (type window window)))
(defun circulate-window-down (window)
(declare (type window window)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values drawable)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-x (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-y (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-width (drawable)
;; For windows, inside width, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-height (drawable)
;; For windows, inside height, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-border-width (drawable)
(declare (type drawable drawable)
(values integer)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun change-property (window property data type format
&key (mode :replace) (start 0) end transform)
;; Start and end affect sub-sequence extracted from data.
;; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type integer start)
(type (or null integer) end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
;; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type integer start)
(type (or null integer) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
;; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence keyword))))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defsetf selection-owner (display selection &optional time) (owner)
;; A bit strange, but retains setf form.
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun convert-selection (selection type requestor &optional property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p display &allow-other-keys)
;; Additional arguments depend on event-key, and are as specified further below
;; with declare-event, except that both resource-ids and resource objects are
;; accepted in the event components. The display argument is only required if the
;; window is :pointer-window or :input-focus.
(declare (type (or window (member :pointer-window :input-focus)) window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)
(type (or null display) display)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &optional cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &optional time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :reply-pointer
:async-keyboard :sync-keyboard :replay-keyboard)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
;; The body is not surrounded by a with-display.
)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:09 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 2 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095718.6.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
(defun query-pointer (window)
(declare (type window window)
(values x y same-screen-p child mask root-x root-y root)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root-x root-y root)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
;; If src and dst are not on the same screen, nil is returned.
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
;; Passing in a zero src-width or src-height is a no-op. A null src-width or
;; src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &optional time)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name &optional (cache-p t))
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers. If cache-p
;; is nil, QueryFont results are never cached locally.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
(defun font-cache-p (font)
;; setf'able
(declare (type font font)
(values boolean)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
;; This might not generate a protocol request if the font is reference counted
;; locally.
(declare (type font font)))
(defun text-extents (font string)
(declare (type (or font gcontext) font)
(type string string)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text16-extents (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text-width (font string)
(declare (type (or font gcontext) font)
(type string string)
(values integer)))
(defun text16-width (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values integer)))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gcontext (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache-p t))
;; Only non-nil components are passed on in the request, but for effective caching
;; assumptions have to be made about what the actual protocol defaults are. For
;; all gcontext components, a value of nil causes the default gcontext value to be
;; used. For clip-mask, this implies that an empty rect-seq cannot be represented
;; as a list. Note: use of stringable as font will cause an implicit open-font.
;; Note: papers over protocol SetClipRectangles and SetDashes special cases. If
;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
;; component will have no effect unless the new value differs from the cached
;; value. Component changes (setfs and with-gcontext) are always deferred
;; regardless of the cache mode, and sent over the protocol only when required by a
;; local operation or by an explicit call to force-gcontext-changes.
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null (or integer (sequence integer))) dashes)
(type (or null integer) dash-offset)
(type boolean cache)
(values gcontext)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:
(defun gcontext-<name> (gcontext)
;; The value will be nil if the last value stored is unknown (e.g., the cache was
;; off, or the component was copied from a gcontext with unknown state).
(declare (type gcontext gcontext)
(values <type>)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:
(defsetf gcontext-<name> (gcontext) (value)
(declare (type gcontext gcontext)
(type <type> value)))
(defun gcontext-clip-mask (gcontext)
(declare (type gcontext gcontext)
(values (or null (member :none) pixmap rect-seq)
(or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))
(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
;; Is nil illegal here, or is it transformed to a vector?
;; A bit strange, but retains setf form.
(declare (type gcontext gcontext)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or (member :none) pixmap rect-seq) clip-mask)))
(defun force-gcontext-changes (gcontext)
;; Force any delayed changes.
(declare (type gcontext gcontext)))
(defmacro with-gcontext ((gcontext &key
function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dashes dash-offset)
&body body)
;; Changes gcontext components within the dynamic scope of the body (i.e.,
;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
;; environment. The body is not surrounded by a with-display. If cache-p is nil
;; or the some component states are unknown, this will implement save/restore by
;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
)
(defun copy-gcontext-components (src dst &rest keys)
(declare (type gcontext src dst)
(type (list gcontext-key) keys)))
(defun copy-gcontext (src dst)
(declare (type gcontext src dst))
;; Copies all components.
)
(defun free-gcontext (gcontext)
(declare (type gcontext gcontext)))
(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
;; Passing in a zero width or height is a no-op. A null width or height translates
;; into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gcontext x y)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)))
(defun draw-points (drawable gcontext points &optional relative-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gcontext segments)
(declare (type drawable drawable)
(type gcontext gcontext)
(type seg-seq segments)))
(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gcontext arcs &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type arc-seq arcs)
(type boolean fill-p)))
;; The following image routines are bare minimum. It may be useful to define some
;; form of "image" object to hide representation details and format conversions. It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.
(defun put-raw-image (drawable gcontext data
&key (start 0) depth x y width height (left-pad 0) format)
;; Data must be a sequence of 8-bit quantities, already in the appropriate format
;; for transmission; the caller is responsible for all byte and bit swapping and
;; compaction. Start is the starting index in data; the end is computed from the
;; other arguments.
(declare (type drawable drawable)
(type gcontext gcontext)
(type (sequence integer) data)
(type integer start depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
;; If data is given, it is modified in place (and returned), otherwise a new
;; sequence is created and returned, with a size computed from the other arguments
;; and the returned depth. The sequence is filled with 8-bit quantities, in
;; transmission format; the caller is responsible for any byte and bit swapping and
;; compaction required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-text (drawable gcontext items)
;; For 8-bit indexes only.
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (string string)
;; :font (fontable font)
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)))
(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached. If bytes-p is nil,
;; then array should be an array of integers to be treated as 16-bit quantities,
;; otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type array array)
(type boolean bytes-p)))
(defun draw-text16 (drawable gcontext items &key bytes-p)
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (array array)
;; :font (fontable font)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)
(type boolean bytes-p)
(type (or null integer) end)))
(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type array array)
(type boolean bytes-p)
(type (or null integer) end)))
(defun create-colormap (visual window &optional alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &optional (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
;; If stringables are specified for colors, it is unspecified whether all
;; stringables are first resolved and then a single StoreColors protocol request is
;; issued, or whether multiple StoreColors protocol requests are issued.
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(define-condition device-busy error)
(defsetf keyboard-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
(declare (type display display)
(values key-click-percent bell-percent bell-pitch bell-duration
led-mask global-auto-repeat auto-repeats)))
(defun bell (display &optional (percent-from-normal 0))
;; It is assumed that an eventual audio extension to X will provide more complete
;; control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
;; Acceleration is rationalized if necessary.
(declare (type display display)
(type (or null (member :default) number) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
;; Setf ought to allow multiple values.
;; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
;; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun remove-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun access-hosts (display &key (result-type 'list))
;; The type of host objects returned is not constrained, except that the hosts must
;; be acceptable to add-access-host and remove-access-host.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
;; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
;; setf'able
;; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
;; This is only defined for core events.
;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
;; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
;; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
;; Grants exclusive access to event queue.
)
(defun event-listen (display &optional (timeout 0))
(declare (type display display)
(type (or null number) timeout))
;; Returns the number of events queued locally, if any, else nil. Hangs waiting
;; for events, forever if timeout is nil, else for the specified number of seconds.
)
(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
;; If force-output-p is true, first invokes display-force-output. Invokes handler
;; on each queued event until handler returns non-nil, and that returned object is
;; then returned by process-event. If peek-p is true, then the event is not
;; removed from the queue. If discard-p is true, then events for which handler
;; returns nil are removed from the queue, otherwise they are left in place. Hangs
;; until non-nil is generated for some event, or for the specified timeout (in
;; seconds, if given); however, it is acceptable for an implementation to wait only
;; once on network data, and therefore timeout prematurely. Returns nil on
;; timeout. If handler is a sequence, it is expected to contain handler functions
;; specific to each event class; the event code is used to index the sequence,
;; fetching the appropriate handler. Handler is called with raw resource-ids, not
;; with resource objects. The arguments to the handler are described further below
;; using declare-event.
(declare (type display display)
(type (or (sequence (function (&rest key-vals) t))
(function (&rest key-vals) t))
handler)
(type (or null number) timeout)
(type boolean peek-p)))
(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
&body clauses)
(declare (arglist (display &key timeout peek-p discard-p force-output-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
;; If force-output-p is true, first invokes display-force-output. Executes the
;; matching clause for each queued event until a clause returns non-nil, and that
;; returned object is then returned by event-case. If peek-p is true, then the
;; event is not removed from the queue. If discard-p is true, then events for
;; which the clause returns nil are removed from the queue, otherwise they are left
;; in place. Hangs until non-nil is generated for some event, or for the specified
;; timeout (in seconds, if given); however, it is acceptable for an implementation
;; to wait only once on network data, and therefore timeout prematurely. Returns
;; nil on timeout. In each clause, event-or-events is an event-key or a list of
;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
;; (but only in the last clause). The keys are not evaluated, and it is an error
;; for the same key to appear in more than one clause. Args is the list of event
;; components of interest; corresponding values (if any) are bound to variables
;; with these names (i.e., the args are variable names, not keywords, the keywords
;; are derived from the variable names). An arg can also be a (keyword var) form,
;; as for keyword args in a lambda lists. If no t/otherwise clause appears, it is
;; equivalent to having one that returns nil.
)
(defmacro declare-event (event-codes &rest declares)
;; Used to indicate the keyword arguments for handler functions in process-event
;; and event-case. All process-event handlers can have (display display) and
;; (event-key event-key) as keyword arguments, and an event-case clause can also
;; have event-key as an argument.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
;; for key-press and key-release, code is the keycode
;; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
;; The event is put at the head of the queue if append-p is nil, else the tail.
;; Additional arguments depend on event-key, and are as specified above with
;; declare-event, except that both resource-ids and resource objects are accepted
;; in the event components.
(declare (type display display)
(type event-key event-key)
(type boolean append-p)))
∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:32:24 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:31-EDT
Date: Mon, 1 Jun 87 08:31 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol script
To: x3j13@sail.stanford.edu
Message-ID: <870601083150.2.RWS@KILLINGTON.LCS.MIT.EDU>
Mathis requested that I mail out the X protocol document.
I just did, in 6 parts. If you are going to print it
out, and have access to a Unix system, below is a shell
script for generating a toc and an index. Be sure to
set the page length for your printer.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# paginate
# addindex
# This archive created: Fri May 29 11:37:31 1987
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'paginate'
then
echo shar: "will not over-write existing file 'paginate'"
else
cat << \SHAR_EOF > 'paginate'
#!/bin/sh
# Hack attack.
# Assuming this program is stilled called paginate, it is intended to be
# in the form
# paginate spec
# It then generates the files
# spec.paged nearly the same as foo with the exception of
# a header on the top of each page. Pages are
# assumed to be 58 lines long before the header
# gets added.
# spec.toc A page number listing of all the lines that start
# with an upper case letter in column 1, up to but
# not including the first colon.
# spec.index An index built from the x11.spec.toc lines.
today="`date`"
linesPerPage=58
infile=$1
pagedfile=$1.paged
indexfile=$1.index
tocfile=$1.toc
addindex=addindex
wordsfile=/usr/tmp/$1.words
indexinput=/usr/tmp/$1.index-input
grepscript=/usr/tmp/$1.grep-script
rm -f $pagedfile $tocfile $indexfile $wordsfile $grepscript
rm -f $indexinput
echo "Paginating $infile into $pagedfile."
awk '
BEGIN {
date = "'"$today"'";
n = split(date, dateparts);
date = dateparts[3] " " dateparts[2] " " dateparts[6]
FS = ":";
input = "'$infile'";
paged = "'$pagedfile'";
toc = "'$tocfile'";
ind = "'$indexfile'";
words = "'$wordsfile'";
page = 1;
line = 0;
}
{
if ((line == 0) && (NF > 0))
printf("\n") > paged
print > paged
line = line + 1
if (line >= '$linesPerPage') {
page = page + 1
line = 0
printf("%c\n%s%42s%23s %d\n", 12, date, "X/V11 Protocol Specification", "Page", page) > paged
}
}
/↑[A-Z]/ {
l = $1;
while ((length(l) % 4) != 0)
l = l " "
while (length(l) < 70)
l = l " ."
if (l ~ /↑SECTION/)
printf("\n") > toc
printf("%s%5d\n", l, page) > toc
if (l !~ /↑SECTION/)
printf("\"%s\"\n", $1) > words
}
' $infile
cat $addindex >> $wordsfile
echo "Sorting $wordsfile."
sort -udf $wordsfile -o $wordsfile
echo "Generating $grepscript."
awk '{print "echo",$0, "; grep -n", $0, "'$infile'" > "'$grepscript'"}' $wordsfile
echo "Executing $grepscript to generate $indexinput."
sh $grepscript > $indexinput
echo "Producing $indexfile."
awk -F: '
BEGIN {
ind = "'$indexfile'";
}
/↑[A-Z]/ {
if (length(line) > 0)
printf("%s\n", line) > ind
line = sprintf("%-25s", $0)
separator = " "
lastPage = 0
}
/↑[0-9]/ {
pagen = ($1+'$linesPerPage'-1)/'$linesPerPage'
t = split(pagen, pageparts, ".")
page = pageparts[1]
if (lastPage != page)
{
if (length(line) > 73)
{
printf("%s,\n", line) > ind
line = sprintf("%-25s %d", " ", page)
}
else
line = line separator page
separator = ", "
lastPage = page
}
}
END {
printf("%s\n", line) > ind
}
' $indexinput
echo "Cleaning up."
#rm -f $wordsfile $grepscript $indexinput
SHAR_EOF
chmod +x 'paginate'
fi
if test -f 'addindex'
then
echo shar: "will not over-write existing file 'addindex'"
else
cat << \SHAR_EOF > 'addindex'
"OwnerGrabButton"
"EnterWindow"
"LeaveWindow"
"PointerMotion"
"PointerMotionHint"
"ButtonMotion"
"VisibilityChange"
"StructureNotify"
"ResizeRedirect"
"SubstructureNotify"
"SubstructureRedirect"
"FocusChange"
"PropertyChange"
"ColormapChange"
"KeymapState"
SHAR_EOF
fi
exit 0
# End of shell archive
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:25 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 3 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082750.8.RWS@KILLINGTON.LCS.MIT.EDU>
GetGeometry
drawable: DRAWABLE
=>
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors: Drawable
Returns the root and (current) geometry of the drawable. Depth is the
number of bits per pixel for the object. X, y, and border-width will
always be zero for pixmaps. For a window, the x and y coordinates
specify the upper left outer corner of the window relative to its
parent's origin, and the width and height specify the inside size (not
including the border).
It is legal to pass an InputOnly window as a drawable to this request.
QueryTree
window: WINDOW
=>
root: WINDOW
parent: WINDOW or None
children: LISTofWINDOW
Errors: Window
Returns the root, the parent, and children of the window. The children
are listed in bottom-to-top stacking order.
InternAtom
name: STRING8
only-if-exists: BOOL
=>
atom: ATOM or None
Errors: Value, Alloc
Returns the atom for the given name. If only-if-exists is False, then
the atom is created if it does not exist. The string should use the
ASCII encoding, and upper/lower case matters.
The lifetime of an atom is not tied to the interning client. Atoms
remained defined until server reset (see Section 11).
GetAtomName
atom: ATOM
=>
name: STRING8
Errors: Atom
Returns the name for the given atom.
ChangeProperty
window: WINDOW
property, type: ATOM
format: {8, 16, 32}
mode: {Replace, Prepend, Append}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Value, Match, Alloc
Alters the property for the specified window. The type is
uninterpreted by the server. The format specifies whether the data
should be viewed as a list of 8-bit, 16-bit, or 32-bit quantities, so
that the server can correctly byte-swap as necessary.
If mode is Replace, the previous property value is discarded. If the
mode is Prepend or Append, then the type and format must match the
existing property value (else a Match error); if the property is
undefined, it is treated as defined with the correct type and format
with zero-length data. For Prepend, the data is tacked on to the
beginning of the existing data, and for Append it is tacked on to the
end of the existing data.
Generates a PropertyNotify event on the window.
The lifetime of a property is not tied to the storing client.
Properties remain until explicitly deleted, or the window is destroyed,
or until server reset (see Section 11).
The maximum size of a property is server dependent.
DeleteProperty
window: WINDOW
property: ATOM
Errors: Window, Atom
Deletes the property from the specified window if the property exists.
Generates a PropertyNotify event on the window unless the property does
not exist.
GetProperty
window: WINDOW
property: ATOM
type: ATOM or AnyPropertyType
long-offset, long-length: CARD32
delete: BOOL
=>
type: ATOM
format: {8, 16, 32}
bytes-after: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Property, Match, Value
If the specified property does not exist for the specifed window, a
Property error is generated. Otherwise, if type AnyPropertyType is
specified, (part of) the property is returned regardless of its type;
if a type is specified, (part of) the property is returned only if its
type equals the specified type (else a Match error). The actual type
and format of the property are returned.
Define the following values:
N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 * long-offset
T = N - I
L = MINIMUM(T, 4 * long-length)
A = N - (I + L)
The returned value starts at byte index I in the property (indexing
from 0), and its length in bytes is L. It is a Value error if
long-offset is given such that L is negative. The value of bytes-after
is A, giving the number of trailing unread bytes in the stored
property.
If delete is True and bytes-after is zero, the property is also deleted
from the window and a PropertyNotify event is generated on the window.
RotateProperties
window: WINDOW
delta: INT8
properties: LISTofATOM
Errors: Window, Atom, Match
If the property names in the list are viewed as being numbered starting
from zero, and there are N property names in the list, then the value
associated with property name I becomes the value associated with
property name (I + delta) mod N, for all I from zero to N - 1. The
effect is to rotate the states by delta places around the virtual ring
of property names (right for positive delta, left for negative delta).
A PropertyNotify event is generated for each property, in the order
listed.
If an atom occurs more than once in the list or no property with that
name is defined for the window, a Match error is generated. If an Atom
or Match error is generated, no properties are changed.
ListProperties
window: WINDOW
=>
atoms: LISTofATOM
Errors: Window
Returns the atoms of properties currently defined on the window.
SetSelectionOwner
selection: ATOM
owner: WINDOW or None
time: TIMESTAMP or CurrentTime
Error: Atom, Window
Changes the owner and last-change time of the specifed selection. The
request has no effect if the specified time is earlier than the current
last-change time of the specified selection or is later than the
current server time; otherwise, the last-change time is set to the
specified time, with CurrentTime replaced by the current server time.
If the new owner is not the same as the current owner of the selection,
and the current owner is a window, then the current owner is sent a
SelectionClear event.
If the owner of a selection is a window, and the window is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
The selection atom is uninterpreted by the server.
Selections are global to the server.
GetSelectionOwner
selection: ATOM
=>
owner: WINDOW or None
Errors: Atom
Returns the current owner of the specified selection, if any.
ConvertSelection
selection, target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Error: Atom, Window
If the specified selection is owned by a window, the server sends a
SelectionRequest event to the owner. If no owner for the specified
selection exists, the server generates a SelectionNotify event to the
requestor with property None. The arguments are passed on unchanged in
either event.
SendEvent
destination: WINDOW or PointerWindow or InputFocus
propagate: BOOL
event-mask: SETofEVENT
event: <normal-event-format>
Errors: Window, Value
If PointerWindow is specified, destination is replaced with the window
that the pointer is in. If InputFocus is specified, then if the focus
window contains the pointer, destination is replaced with the window
that the pointer is in, and otherwise destination is replaced with the
focus window.
If propagate is False, then the event is sent to every client selecting
on destination any of the event types in event-mask.
If propagate is True and no clients have selected on destination any of
the event types in event-mask, then destination is replaced with the
closest ancestor of destination for which some client has selected a
type in event-mask and no intervening window has that type in its
do-not-propagate-mask. If no such window exists, or if the window is
an ancestor of the focus window and InputFocus was originally specified
as the destination, then the event is not sent to any clients.
Otherwise, the event is reported to every client selecting on the final
destination any of the types specified in event-mask.
The event code must be one of the core events, or one of the events
defined by an extension, so that the server can correctly byte swap the
contents as necessary. The contents of the event are otherwise
unaltered and unchecked by the server except to force on the most
significant bit of the event code.
Active grabs are ignored for this request.
GrabPointer
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Cursor, Window, Value
Actively grabs control of the pointer. Further pointer events are only
reported to the grabbing client. The request overrides any active
pointer grab by this client.
Event-mask is always augmented to include ButtonPress and
ButtonRelease. If owner-events is False, all generated pointer events
are reported with respect to grab-window, and are only reported if
selected by event-mask. If owner-events is True, then if a generated
pointer event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window, and is only reported if selected by event-mask. For
either value of owner-events, unreported events are simply discarded.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
If a cursor is specified, then it is displayed regardless of what
window the pointer is in. If no cursor is specified, then when the
pointer is in grab-window or one of its subwindows, the normal cursor
for that window is displayed, and otherwise the cursor for grab-window
is displayed.
If a confine-to window is specified, then the pointer will be
restricted to stay contained in that window. The confine-to window
need have no relationship to the grab-window. If the pointer is not
initially in the confine-to window, then it is warped automatically to
the closest edge (and enter/leave events generated normally) just
before the grab activates. If the confine-to window is subsequently
reconfigured, the pointer will be warped automatically as necessary to
keep it contained in the window.
This request generates EnterNotify and LeaveNotify events.
The request fails with status AlreadyGrabbed if the pointer is actively
grabbed by some other client. The request fails with status Frozen if
the pointer is frozen by an active grab of another client. The request
fails with status NotViewable if grab-window or confine-to window is
not viewable. The request fails with status InvalidTime if the
specified time is earlier than the last-pointer-grab time or later than
the current server time; otherwise the last-pointer-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabPointer
time: TIMESTAMP or CurrentTime
Releases the pointer if this client has it actively grabbed (from
either GrabPointer or GrabButton or from a normal button press), and
releases any queued events. The request has no effect if the specified
time is earlier than the last-pointer-grab time or is later than the
current server time.
This request generates EnterNotify and LeaveNotify events.
An UngrabPointer is performed automatically if the event window or
confine-to window for an active pointer grab becomes not viewable.
GrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
Errors: Cursor, Window, Value, Access
This request establishes a passive grab. In the future, if the
specified button is pressed when the specified modifier keys are down
(and no other buttons or modifier keys are down), and grab-window
contains the pointer, and the confine-to window (if any) is viewable,
and these constraints are not satisfied for any ancestor, then the
pointer is actively grabbed as described in GrabPointer, the
last-pointer-grab time is set to the time at which the button was
pressed (as transmitted in the ButtonPress event), and the ButtonPress
event is reported. The interpretation of the remaining arguments is as
for GrabPointer. The active grab is terminated automatically when all
buttons are released (independent of the state of modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A button of AnyButton is equivalent to
issuing the request for all possible buttons.
An Access error is generated if some other client has already issued a
GrabButton with the same button/key combination on the same window.
When using AnyModifier or AnyButton, the request fails completely (no
grabs are established) if there is a conflicting grab for any
combination. The request has no effect on an active grab.
UngrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
Errors: Window
Releases the passive button/key combination on the specified window if
it was grabbed by this client. A modifiers of AnyModifier is
equivalent to issuing the request for all possible modifier
combinations. A button of AnyButton is equivalent to issuing the
request for all possible buttons. Has no effect on an active grab.
ChangeActivePointerGrab
event-mask: SETofPOINTEREVENT
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
Errors: Cursor
Changes the specified dynamic parameters if the pointer is actively
grabbed by the client and the specified time is no earlier than the
last-pointer-grab time and no later than the current server time. The
interpretation of event-mask and cursor are as in GrabPointer. The
event-mask is always augmented to include ButtonPress and
ButtonRelease. Has no effect on the passive parameters of a
GrabButton.
GrabKeyboard
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Window, Value
Actively grabs control of the keyboard. Further key events are
reported only to the grabbing client. The request overrides any active
keyboard grab by this client.
If owner-events is False, all generated key events are reported with
respect to grab-window. If owner-events is True, then if a generated
key event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window. Both KeyPress and KeyRelease events are always reported,
independent of any event selection made by the client.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
This request generates FocusIn and FocusOut events.
The request fails with status AlreadyGrabbed if the keyboard is
actively grabbed by some other client. The request fails with status
Frozen if the keyboard is frozen by an active grab of another client.
The request fails with status NotViewable if grab-window is not
viewable. The request fails with status InvalidTime if the specified
time is earlier than the last-keyboard-grab time or later than the
current server time; otherwise the last-keyboard-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabKeyboard
time: TIMESTAMP or CurrentTime
Releases the keyboard if this client has it actively grabbed (from
either GrabKeyboard or GrabKey), and releases any queued events. The
request has no effect if the specified time is earlier than the
last-keyboard-grab time or is later than the current server time.
This request generates FocusIn and FocusOut events.
An UngrabKeyboard is performed automatically if the event window for an
active keyboard grab becomes not viewable.
GrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
Errors: Window, Value, Access
This request establishes a passive grab on the keyboard. In the
future, if the specified key (which can itself be a modifier key) is
pressed when the specified modifier keys are down (and no other
modifier keys are down), and the KeyPress event would be generated in
grab-window or one of its inferiors, and these constraints are not
satisfied for any ancestor, then the keyboard is actively grabbed as
described in GrabKeyboard, the last-keyboard-grab time is set to the
time at which the key was pressed (as transmitted in the KeyPress
event), and the KeyPress event is reported. The interpretation of the
remaining arguments is as for GrabKeyboard. The active grab is
terminated automatically when the specified key has been released
(independent of the state of the modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A key of AnyNonModifier is equivalent
to issuing the request for all possible non-modifier key codes.
An Access error is generated if some other client has issued a GrabKey
with the same key combination on the same window. When using
AnyModifier or AnyNonModifier, the request fails completely (no grabs
are established) if there is a conflicting grab for any combination.
UngrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
Errors: Window
Releases the key combination on the specified window if it was grabbed
by this client. A modifiers of AnyModifier is equivalent to issuing
the request for all possible modifier combinations. A key of
AnyNonModifier is equivalent to issuing the request for all possible
non-modifier key codes. Has no effect on an active grab.
AllowEvents
mode: {AsyncPointer, SyncPointer, ReplayPointer,
AsyncKeyboard, SyncKeyboard, ReplayKeyboard}
time: TIMESTAMP or CurrentTime
Errors: Value
Releases some queued events if the client has caused a device to
freeze. The request has no effect if the specified time is earlier
than the last-grab time of the most recent active grab for the client,
or if the specified time is later than the current server time.
For AsyncPointer, if the pointer is frozen by the client, pointer event
processing continues normally. If the pointer is frozen twice by the
client on behalf of two separate grabs, AsyncPointer "thaws" for both.
AsyncPointer has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
For SyncPointer, if the pointer is frozen and actively grabbed by the
client, pointer event processing continues normally until the next
ButtonPress or ButtonRelease event is reported to the client, at which
time the pointer again appears to freeze. However if the reported
event causes the pointer grab to be released, then the pointer does not
freeze. SyncPointer has no effect if the pointer is not frozen by the
client, or if the pointer is not grabbed by the client.
For ReplayPointer, if the pointer is actively grabbed by the client and
is frozen as the result of an event having been sent to the client
(either from the activation of a GrabButton, or from a previous
AllowEvents with mode SyncPointer, but not from a GrabPointer), then
the pointer grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the pointer is not grabbed by the client, or if the pointer is not
frozen as the result of an event.
For AsyncKeyboard, if the keyboard is frozen by the client, keyboard
event processing continues normally. If the pointer is frozen twice by
the client on behalf of two separate grabs, AsyncPointer "thaws" for
both. AsyncKeyboard has no effect if the keyboard is not frozen by the
client, but the keyboard need not be grabbed by the client.
For SyncKeyboard, if the keyboard is frozen and actively grabbed by the
client, keyboard event processing continues normally until the next
KeyPress or KeyRelease event is reported to the client, at which time
the keyboard again appears to freeze. However if the reported event
causes the keyboard grab to be released, then the keyboard does not
freeze. SyncKeyboard has no effect if the keyboard is not frozen by
the client, or if the keyboard is not grabbed by the client.
For ReplayKeyboard, if the keyboard is actively grabbed by the client
and is frozen as the result of an event having been sent to the client
(either from the activation of a GrabKey, or from a previous
AllowEvents with mode SyncKeyboard, but not from a GrabKeyboard), then
the keyboard grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the keyboard is not grabbed by the client, or if the keyboard is not
frozen as the result of an event.
AsyncPointer, SyncPointer, and Replay Pointer have no effect on
processing of keyboard events. AsyncKeyboard, SyncKeyboard, and
ReplayKeyboard have no effect on processing of pointer events.
It is possible for both a pointer grab and a keyboard grab to be active
simultaneously (by the same or different clients). If a device is
frozen on behalf of either grab, no event processing is performed for
the device. It is possible for a single device to be frozen due to
both grabs. In this case, the freeze must be released on behalf of
both grabs before events can again be processed.
GrabServer
Disables processing of requests and close-downs on all other
connections (than the one this request arrived on).
UngrabServer
Restarts processing of requests and close-downs on other connections.
QueryPointer
window: WINDOW
=>
root: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, win-x, win-y: INT16
mask: SETofKEYBUTMASK
Errors: Window
The root window the pointer is currently on, and pointer coordinates
relative to the root's origin, are returned. If same-screen is False,
then the pointer is not on the same screen as the argument window, and
child is None and win-x and win-y are zero. If same-screen is True,
then win-x and win-y are the pointer coordinates relative to the
argument window's origin, and child is the child containing the
pointer, if any. The current state of the modifier keys and the
buttons are also returned.
GetMotionEvents
start, stop: TIMESTAMP or CurrentTime
window: WINDOW
=>
events: LISTofTIMECOORD
where
TIMECOORD: {x, y: CARD16
time: TIMESTAMP}
Error: Window
Returns all events in the motion history buffer that fall between the
specified start and stop times (inclusive) and that have coordinates
that lie within (including borders) the specified window at its present
placement. The x and y coordinates are reported relative to the origin
of the window.
TranslateCoordinates
src-window, dst-window: WINDOW
src-x, src-y: INT16
=>
same-screen: BOOL
child: WINDOW or None
dst-x, dst-y: INT16
Errors: Window
The src-x and src-y coordinates are taken relative to src-window's
origin, and returned as dst-x and dst-y coordinates relative to
dst-window's origin. If same-screen is False, then src-window and
dst-window are on different screens, and dst-x and dst-y are zero. If
the coordinates are contained in a mapped child of dst-window, then
that child is returned.
WarpPointer
src-window: WINDOW or None
dst-window: WINDOW
src-x, src-y: INT16
src-width, src-height: CARD16
dst-x, dst-y: INT16
Errors: Window
Moves the pointer to [dst-x, dst-y] relative to dst-window's origin.
If src-window is None, the move is independent of the current pointer
position, but if a window is specified, the move only takes place if
the pointer is currently contained in a visible portion of the
specified rectangle of the src-window.
The src-x and src-y coordinates are relative to src-window's origin.
If src-height is zero, it is replaced with the current height of
src-window minus src-y. If src-width is zero, it is replaced with the
current width of src-window minus src-x.
This request cannot be used to move the pointer outside the confine-to
window of an active pointer grab; an attempt will only move the pointer
as far as the closest edge of the confine-to window.
SetInputFocus
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
time: TIMESTAMP or CurrentTime
Errors: Window, Value
Changes the input focus and the last-focus-change time. The request
has no effect if the specified time is earlier than the current
last-focus-change time or is later than the current server time;
otherwise, the last-focus-change time is set to the specified time,
with CurrentTime replaced by the current server time.
If None is specified as the focus, all keyboard events are discarded
until a new focus window is set. In this case, the revert-to argument
is ignored.
If a window is specified as the focus, it becomes the keyboard's focus
window. If a generated keyboard event would normally be reported to
this window or one of its inferiors, the event is reported normally;
otherwise, the event is reported with respect to the focus window.
If PointerRoot is specified as the focus, the focus window is
dynamically taken to be the root window of whatever screen the pointer
is on at each keyboard event. In this case, the revert-to argument is
ignored.
This request generates FocusIn and FocusOut events.
If the focus window becomes not viewable, the new focus window depends
on the revert-to argument. If revert-to is Parent, the focus reverts
to the parent (or the closest viewable ancestor) and the new revert-to
value is take to be None. If revert-to is PointerRoot or None, the
focus reverts to that value. When the focus reverts, FocusIn and
FocusOut events are generated, but the last-focus-change time is not
affected.
GetInputFocus
=>
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
Returns the current focus state.
QueryKeymap
=>
keys: LISTofCARD8
Returns a bit vector for the keyboard; each one bit indicates that the
corresponding key is currently pressed. The vector is represented as
32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N+7, with
the least significant bit in the byte representing key 8N.
OpenFont
fid: FONT
name: STRING8
Errors: IDChoice, Name, Alloc
Loads the specified font, if necessary, and associates identifier fid
with it. The font can be used as a source for any drawable. The font
name should use the ASCII encoding, and upper/lower case does not
matter.
CloseFont
font: FONT
Errors: Font
Deletes the association between the resource id and the font. The font
itself will be freed when no other resource references it.
∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:29:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 5 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082843.0.RWS@KILLINGTON.LCS.MIT.EDU>
PolyArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
Draws circular or elliptical arcs. Each arc is specified by a
rectangle and two angles. The x and y coordinates are relative to the
origin of the drawable, and define the upper left corner of the
rectangle. The center of the circle or ellipse is the center of the
rectangle, and the major and minor axes are specified by the width and
height, respectively. The angles are signed integers in degrees scaled
by 64, with positive indicating counterclockwise motion and negative
indicating clockwise motion. The start of the arc is specified by
angle1 relative to the three-oclock position from the center, and the
path and extent of the arc is specified by angle2 relative to the start
of the arc. If the magnitude of angle2 is greater than 360 degrees, it
is truncated to 360 degrees.
The arcs are drawn in the order listed. If the last point in one arc
coincides with the first point in the following arc, the two arcs will
join correctly. If the first point in the first arc coincides with the
last point in the last arc, the two arcs will join correctly. For any
given arc, no pixel is drawn more than once. If two arcs join
correctly and the line-width is greater than zero and the arcs
intersect, no pixel is drawn more than once. Otherwise, the
intersecting pixels of intersecting arcs are drawn multiple times.
Specifying an arc with one endpoint and a clockwise extent draws the
same pixels as specifying the other endpoint and an equivalent
counterclockwise extent, except as it affects joins.
By specifying one axis to be zero, a horizontal or vertical line can be
drawn.
Angles are computed based solely on the coordinate system, ignoring the
aspect ratio.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
FillPoly
drawable: DRAWABLE
gc: GCONTEXT
shape: {Complex, Nonconvex, Convex}
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Match, Value
Fills the region closed by the specified path. The path is closed
automatically if the last point in the list does not coincide with the
first point. No pixel of the region is drawn more than once.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
The shape parameter may be used by the server to improve performance.
Complex means the path may self-intersect.
Nonconvex means the path does not self-intersect, but the shape is not
wholly convex. If known by the client, specifying Nonconvex over
Complex may improve performance. If Nonconvex is specified for a
self-intersecting path, the graphics results are undefined.
Convex means the path is wholly convex. If known by the client,
specifying Convex can improve performance. If Convex is specified for
a path that is not convex, the graphics results are undefined.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Fills the specified rectangles. The x and y coordinates of each
rectangle are relative to the drawable's origin, and define the upper
left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
For each arc, fills the region closed by the specified arc and one or
two line segments, depending on the arc-mode. For Chord, the single
line segment joining the endpoints of the arc is used. For PieSlice,
the two line segments joining the endpoints of the arc with the center
point are used. The arcs are as specified in the PolyArc request.
The arcs are filled in the order listed. For any given arc, no pixel
is drawn more than once. If regions intersect, the intersecting pixels
are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
arc-mode, subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PutImage
drawable: DRAWABLE
gc: GCONTEXT
depth: CARD8
width, height: CARD16
dst-x, dst-y: INT16
left-pad: CARD8
format: {Bitmap, XYPixmap, ZPixmap}
bits: <bits>
Errors: Drawable, GContext, Match, Value, Alloc
Combines an image with a rectangle of the drawable. The dst-x and
dst-y coordinates are relative to the drawable's origin.
If Bitmap format is used, then depth must be one (else a Match error)
and the image must be in XYFormat. The foreground pixel in gc defines
the source for one bits in the image, and the background pixel defines
the source for the zero bits.
For XYPixmap and ZPixmap, depth must match the depth of drawable (else
a Match error). For XYPixmap, the image must be sent in XYFormat. For
ZPixmap, the image must be sent in the ZFormat defined for the given
depth.
The left-pad must be zero for ZPixmap format. For Bitmap and XYPixmap
format, left-pad must be less than bitmap-format-scanline-pad (as given
in the server connection setup info). The first left-pad bits in every
scanline are to be ignored by the server; the actual image begins that
many bits into the data. The width argument defines the width of the
actual image, and does not include left-pad.
GC components: alu-function, plane-mask, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background
GetImage
drawable: DRAWABLE
x, y: INT16
width, height: CARD16
plane-mask: CARD32
format: {XYFormat, ZFormat}
=>
depth: CARD8
visual: VISUALID or None
bits: <bits>
Errors: Drawable, Value, Match
Returns the contents of the given rectangle of the drawable in the
given format. The x and y coordinates are relative to the drawable's
origin, and define the upper left corner of the rectangle. If XYFormat
is specified, only the bit planes specified in plane-mask are
transmitted. If ZFormat is specified, then bits in all planes not
specified in plane-mask transmitted as zero. The returned depth
specifies the number of bits per pixel of the image. If the drawable
is a window, its visual type is returned; if the drawable is a pixmap,
the visual is None.
If the drawable is a window, the window must be mapped, and it must be
the case that, if there were no inferiors or overlapping windows, the
specified rectangle of the window would be fully visible on the screen
(else a Match error). The returned image will include any visible
portions of inferiors or overlapping windows contained in the
rectangle, but if these windows are of different depth than the
specified window, the contents returned for them are not defined by the
core protocol.
PolyText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM8
where
TEXTITEM8: TEXTELT8 or FONT
TEXTELT8: [delta: INT8
string: STRING8]
Errors: Drawable, GContext, Match, Font
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). Each
text item is processed in turn. A font item causes the font to be
stored in gc, and to be used for subsequent text; switching among fonts
with differing draw-directions is permitted. A text element delta
specifies an additional change in the position along the x axis before
the string is drawn; the delta is always added to the character origin
(not added or subtracted based on the draw-direction of the current
font). Each character image, as defined by the font in gc, is treated
as an additional mask for a fill operation on the drawable.
All contained FONTs are always transmitted most significant byte first.
If a Font error is generated for an item, the previous items may have
been drawn.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: alu-function, plane-mask, fill-style, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM16
where
TEXTITEM16: TEXTELT16 or FONT
TEXTELT16: [delta-x: INT8
string: STRING16]
Errors: Drawable, GContext, Match, Font
Just like PolyText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
ImageText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING8
Errors: Drawable, GContext, Match
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). The
effect is to first fill a destination rectangle with the background
pixel defined in gc, and then paint the text with the foreground pixel.
The upper left corner of the filled rectangle is at
[x + overall-left, y - font-ascent]
the width is
overall-right - overall-left
and the height is
font-ascent + font-descent
where overall-left, overall-right, font-ascent, and font-descent are as
would be returned by a QueryTextExtents call using gc and string.
The alu-function and fill-style defined in gc are ignored for this
request; the effective alu-function is Copy and the effective
fill-style Solid.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: plane-mask, foreground, background, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
ImageText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING16
Errors: Drawable, GContext, Match
Just like ImageText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
CreateColormap
mid: COLORMAP
visual: VISUALID
window: WINDOW
alloc: {None, All}
Errors: IDChoice, Window, Value, Match, Alloc
Creates a colormap of the specified visual type for the screen on which
the window resides, and associates the identifier mid with it. The
visual type must be one supported by the screen, and cannot be of class
TrueColor (else a Match error). The initial values of the colormap
entries are undefined for classes GrayScale, PseudoColor, and
DirectColor; for StaticGray, StaticColor, and TrueColor, the entries
will have defined values, but those values are specific to the visual
and are not defined by the core protocol. For StaticGray, StaticColor,
and TrueColor, alloc must be specified as None (else a Match error).
For the other classes, if alloc is None, the colormap initially has no
allocated entries, and clients can allocate entries. If alloc is All,
then the entire colormap is "allocated" writable, but entries cannot be
freed with FreeColors, and no relationships among entries is defined;
the client must understand whether the colormap is GrayScale,
PseudoColor, or DirectColor to know how to store into entries.
FreeColormap
cmap: COLORMAP
Errors: Colormap
Deletes the association between the resource id and the colormap. If
the colormap is an installed map for a screen, it is uninstalled (see
UninstallColormap). If the colormap is defined as the colormap for a
window (via CreateWindow or ChangeWindowAttributes), the colormap for
the window is changed to None, and a ColormapNotify event is generated.
The colors displayed for a window with a colormap of None are not
defined by the protocol.
Has no effect on a default colormap for a screen.
CopyColormapAndFree
mid, src-cmap: COLORMAP
Errors: Colormap, Alloc
Creates a colormap for the same screen as src-cmap, and associates
identifier mid with it. Moves all of the client's existing allocations
from src-cmap to the new colormap, and frees those entries in src-cmap.
Values in other entries in the new colormap are undefined.
InstallColormap
cmap: COLORMAP
Errors: Colormap
Makes this colormap an installed map for its screen. All windows
associated with this colormap immediately display with true colors. As
a side-effect, previously installed colormaps may be uninstalled, and
other windows may display with false colors. Which colormaps get
uninstalled is server dependent, except that it is guaranteed that the
M-1 most recently client-installed colormaps will not be uninstalled,
where M is the min-installed-maps specified for the screen in the
connection setup.
If cmap is not already an installed map, a ColormapNotify event is
generated on every window having cmap as an attribute. If a colormap
is uninstalled as a result of the install, a ColormapNotify event is
generated on every window having that colormap as an attribute.
Initially only the default colormap for a screen is installed.
UninstallColormap
cmap: COLORMAP
Errors: Colormap
If cmap is an installed map for its screen, one or more colormaps are
installed in its place; the choice is server dependent, except that if
the screen's default colormap is not installed and can be installed
(without forcing other colormaps out), then the default colormap is
used.
If cmap is an installed map, a ColormapNotify event is generated on
every window having this colormap as an attribute. If a colormap is
installed as a result of the uninstall, a ColormapNotify event is
generated on every window having that colormap as an attribute.
ListInstalledColormaps
window: WINDOW
=>
cmaps: LISTofCOLORMAP
Errors: Window
Returns a list of the currently installed colormaps for the screen of
the specified window.
AllocColor
cmap: COLORMAP
red, green, blue: CARD16
=>
pixel: CARD32
red, green, blue: CARD16
Errors: Colormap, Alloc
Allocates a read-only colormap entry corresponding to the closest RGB
values provided by the hardware. Returns the pixel and the RGB values
actually used.
AllocNamedColor
cmap: COLORMAP
name: STRING8
=>
pixel: CARD32
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name, Alloc
Looks up the named color with respect to the screen associated with the
colormap, then does an AllocColor on cmap. The name should use the
ASCII encoding, and upper/lower case does not matter. The exact RGB
values specify the "true" values for the color, and the screen values
specify the values actually used in the colormap.
AllocColorCells
cmap: COLORMAP
colors, planes: CARD16
contiguous: BOOL
=>
pixels, masks: LISTofCARD32
Errors: Colormap, Value, Alloc
The number of colors must be positive, the number of planes
non-negative. If C colors and P planes are requested, then C pixels
and P masks are returned. No mask will have any bits in common with
any other mask, or with any of the pixels. By ORing together masks and
pixels, C*(2↑P) distinct pixels can be produced; all of these are
allocated writable by the request. For GrayScale or PseudoColor, each
mask will have exactly one bit, and for DirectColor each will have
exactly three bits. If contiguous is True, then if all masks are ORed
together, a single contiguous set of bits will be formed for GrayScale
or PseudoColor, and three contiguous sets of bits (one within each
pixel subfield) for DirectColor. The RGB values of the allocated
entries are undefined.
AllocColorPlanes
cmap: COLORMAP
colors, reds, greens, blues: CARD16
contiguous: BOOL
=>
pixels: LISTofCARD32
red-mask, green-mask, blue-mask: CARD32
Errors; Colormap, Value, Alloc
The number of colors must be positive, the reds, greens, and blues
non-negative. If C colors, R reds, G greens, and B blues are
requested, then C pixels are returned, and the masks have R, G, and B
bits set respectively. If contiguous is True, then each mask will have
a contiguous set of bits. No mask will have any bits in common with
any other mask, or with any of the pixels. For DirectColor, each mask
will lie within the corresponding pixel subfield. By ORing together
subsets of masks with pixels, C*(2↑(R+G+B)) distinct pixels can be
produced; all of these are allocated by the request. The initial RGB
values of the allocated entries are undefined. In the colormap there
are only C*(2↑R) independent red entries, C*(2↑G) independent green
entries, and C*(2↑B) independent blue entries. This is true even for
PseudoColor. When the colormap entry for a pixel value is changed
using StoreColors or StoreNamedColor, the pixel is decomposed according
to the masks and the corresponding independent entries are updated.
FreeColors
cmap: COLORMAP
pixels: LISTofCARD32
plane-mask: CARD32
Errors: Colormap, Access, Value
The plane-mask should not have any bits in common with any of the
pixels. The set of all pixels is produced by ORing together subsets of
plane-mask with the pixels. The request frees all of these pixels.
Note that freeing an individual pixel obtained from AllocColorPlanes
may not actually allow it to be reused until all of its "related"
pixels are also freed.
All specified pixels that are allocated by the client in cmap are
freed, even if one or more pixels produce an error. A Value error is
generated if a specified pixel is not a valid index into cmap, and an
Access error is generated if a specified pixel is not allocated by the
client (i.e., is unallocated or is only allocated by another client).
If more than one pixel is in error, which one is reported is arbitrary.
StoreColors
cmap: COLORMAP
items: LISTofCOLORITEM
where
COLORITEM: [pixel: CARD32
do-red, do-green, do-blue: BOOL
red, green, blue: CARD16]
Errors: Colormap, Access, Value
Changes the colormap entries of the specified pixels. The do-red,
do-green, and do-blue fields indicate which components should actually
be changed. If the colormap is an installed map for its screen, the
changes are visible immediately.
All specified pixels that are allocated writable in cmap (by any
client) are changed, even if one or more pixels produce an error. A
Value error is generated if a specified pixel is not a valid index into
cmap, and an Access error is generated if a specified pixel is
unallocated or is allocated read-only. If more than one pixel is in
error, which one is reported is arbitrary.
StoreNamedColor
cmap: COLORMAP
pixel: CARD32
name: STRING8
do-red, do-green, do-blue: BOOL
Errors: Colormap, Name, Access, Value
Looks up the named color with respect to the screen associated with
cmap, then does a StoreColors in cmap. The name should use the ASCII
encoding, and upper/lower case does not matter.
QueryColors
cmap: COLORMAP
pixels: LISTofCARD32
=>
colors: LISTofRGB
where
RGB: [red, green, blue: CARD16]
Errors: Colormap, Value
Returns the color values stored in cmap for the specified pixels. The
values returned for an unallocated entry are undefined. A Value error
is generated if a pixel is not a valid index into cmap. If more than
one pixel is in error, which one is reported is arbitrary.
LookupColor
cmap: COLORMAP
name: STRING8
=>
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name
Looks up the string name of a color with respect to the screen
associated with cmap, and returns both the exact the color values and
the closest values provided by the hardware. The name should use the
ASCII encoding, and upper/lower case does not matter.
CreateCursor
cid: CURSOR
source: PIXMAP
mask: PIXMAP or None
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
x, y: CARD16
Errors: IDChoice, Bitmap, Match, Value, Alloc
Creates a cursor and associates identifier cid with it. Foreground and
background RGB values must be specified, even if the server only has a
monochrome screen. The foreground is used for the one bits in the
source, and the background is used for the zero bits. Both source and
mask (if specified) must have depth one (else a Match error), but can
have any root. The mask pixmap defines the shape of the cursor; that
is, the one bits in the mask define which source pixels will be
displayed. If no mask is given, all pixels of the source are
displayed. The mask, if present, must be the same size as source (else
a Match error). The x and y coordinates define the hotspot, relative
to the source's origin, and must be a point within the source (else a
Match error).
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The pixmaps can be freed immediately if no further explicit references
to them are to be made.
Subsequent drawing in the source or mask pixmap has an undefined effect
on the cursor; the server might or might not make a copy of the pixmap.
CreateGlyphCursor
cid: CURSOR
source-font: FONT
mask-font: FONT or None
source-char, mask-char: CARD16
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: IDChoice, Font, Value, Alloc
Similar to CreateCursor, but the source and mask bitmaps are obtained
from the specified font glyphs. The mask font and character are
optional. The origin of the source glyph defines the hotspot, and the
mask is positioned such that the origins are coincident. The source
and mask need not have the same bounding box metrics. If no mask is
given, all pixels of the source are displayed. Note that source-char
and mask-char are CARD16 (not CHAR2B); for two-byte matrix fonts, the
16-bit value should be formed with byte1 in the most significant byte
and byte2 in the least significant byte.
FreeCursor
cursor: CURSOR
Errors: Cursor
Deletes the association between the resource id and the cursor. The
cursor storage will be freed when no other resource references it.
RecolorCursor
cursor: CURSOR
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: Cursor
Changes the color of a cursor. If the cursor is being displayed on a
screen, the change is visible immediately.
QueryBestSize
class: {Cursor, Tile, Stipple}
drawable: DRAWABLE
width, height: CARD16
=>
width, height: CARD16
Errors: Drawable, Value, Match
Returns the "best" size that is "closest" to the argument size. For
Cursor, this is the largest size that can be fully displayed. For
Tile, this is the size that can be tiled "fastest". For Stipple, this
is the size that can be stippled "fastest".
For Cursor, the drawable indicates the desired screen. For Tile and
Stipple, the drawable indicates screen, and also possibly window class
and depth; an InputOnly window cannot be used as the drawable for Tile
or Stipple (else a Match error).
QueryExtension
name: STRING8
=>
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
Determines if the named extension is present. If so, the major opcode
for the extension is returned, if it has one, otherwise zero is
returned. Any minor opcode and the request formats are specific to the
extension. If the extension involves additional event types, the base
event type code is returned, otherwise zero is returned. The format of
the events is specific to the extension. If the extension involves
additional error codes, the base error code is returned, otherwise
zero is returned. The format of additional data in the errors is
specific to the extension.
The extension name should be in the ASCII encoding, and upper/lower
case matters.
ListExtensions
=>
names: LISTofSTRING8
Returns a list of all extensions supported by the server.
SetKeyboardMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the keyboard. Elements of the list are indexed
starting from one. The list must be of length 255. The index is a
"core" keycode, and the element of the list defines the "effective"
keycode.
A zero element disables a key, no elements can have values 1 through 7,
and no two elements (with index larger than 7) can have the same
non-zero value. If the keyboard does not really generate a given
keycode, specifying a non-zero value for that core keycode has no
effect.
Elements 6 and 7 of the map must always be zero. The first five
elements are special: they specify the keycodes (if any) that
correspond to the Mod1 through Mod5 modifiers. Setting one of these
entries to zero disables use of that modifier bit. No two of the first
five elements can have the same non-zero value.
A server can impose restrictions on how keyboards get remapped, e.g.,
if certain keys do not generate up transitions in hardware.
If any of the keys or modifiers to be altered are currently in the down
state, the status reply is Busy and the mapping is not changed.
GetKeyboardMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the keyboard. Elements of the list are
indexed starting from one. The length of the list is 255.
The nominal mapping for a keyboard is almost the identity mapping,
except that map[i]=0 for keycodes that have no corresponding physical
key, and the first five entries indicate the keycodes (if any)
corresponding to the Mod1 through Mod5 modifier bits.
ChangeKeyboardControl
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Match, Value
Controls various aspects of the keyboard. The value-mask and
value-list specify which controls are to be changed. The possible
values are:
key-click-percent: INT8
bell-percent: INT8
bell-pitch: INT16
bell-duration: INT16
led: CARD8
led-mode: {On, Off}
key: KEYCODE
auto-repeat-mode: {On, Off, Default}
Key-click-percent sets the volume for key clicks between 0 (off) and
100 (loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
Setting to -1 restores the default. Other negative values generate a
Value error.
Bell-duration sets the duration (specified in milliseconds) of the
bell, if possible. Setting to -1 restores the default. Other negative
values generate a Value error.
If both led-mode and led are specified, then the state of that LED is
changed, if possible. If only led-mode is specified, then the state of
all LEDs are changed, if possible. At most 32 LEDs are supported,
numbered from one. It is a Match error if an led is specified without
an led-mode.
If both auto-repeat-mode and key are specified, then the auto-repeat
mode of that key is changed, if possible. If only auto-repeat-mode is
specified, then the global auto-repeat mode for the entire keyboard is
changed, if possible, without affecting the per-key settings. It is a
Match error if a key is specified without an auto-repeat-mode.
A bell generator connected with the console but not directly on the
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server
dependent. If an error is generated, a subset of the controls may have
been altered.
GetKeyboardControl
=>
key-click-percent: CARD8
bell-percent: CARD8
bell-pitch: CARD16
bell-duration: CARD16
led-mask: CARD32
global-auto-repeat: {On, Off}
auto-repeats: LISTofCARD8
Errors: Match
Returns the current control values for the keyboard. For the LEDs, the
least significant bit of led-mask corresponds to LED one, and each one
bit in led-mask indicates an LED that is lit. Auto-repeats is a bit
vector; each one bit indicates that auto-repeat is enabled for the
corresponding key. The vector is represented as 32 bytes. Byte N
(from 0) contains the bits for keys 8N to 8N+7, with the least
significant bit in the byte representing key 8N.
Bell
percent: INT8
Errors: Match, Value
Rings the bell on the keyboard at the specified volume relative to the
base volume for the keyboard, if possible. Percent, which can range
from -100 to 100 inclusive, is added to the base volume, and the sum
limited to the range 0 to 100 inclusive.
∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 1 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082645.6.RWS@KILLINGTON.LCS.MIT.EDU>
X WINDOW SYSTEM PROTOCOL, VERSION 11
Alpha Update
April 1987
Copyright (c) 1986, 1987 Massachusetts Institute of Technology
X Window System is a trademark of M.I.T.
Permission to use, copy, modify, and distribute this document for any purpose
and without fee is hereby granted, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission
notice are retained, and that the name of M.I.T. not be used in advertising or
publicity pertaining to this document without specific, written prior
permission. M.I.T. makes no representations about the suitability of this
document or the protocol defined in this document for any purpose. It is
provided "as is" without express or implied warranty.
Author: Robert W. Scheifler
Laboratory for Computer Science
545 Technology Square, Room 418
Cambridge, MA 02139
Contributors:
Dave Carver (Digital HPW)
Branko Gerovac (Digital HPW)
Jim Gettys (MIT/Project Athena, Digital)
Phil Karlton (Digital WSL)
Scott McGregor (Digital SSG)
Ram Rao (Digital UEG)
David Rosenthal (Sun)
Dave Winchell (Digital UEG)
Implementors of initial server who provided useful input:
Susan Angebranndt (Digital)
Raymond Drewry (Digital)
Todd Newman (Digital)
Invited reviewers who provided useful input:
Andrew Cherenson (Berkeley)
Burns Fisher (Digital)
Dan Garfinkel (HP)
Leo Hourvitz (Next)
Brock Krizan (HP)
David Laidlaw (Stellar)
Dave Mellinger (Interleaf)
Ron Newman (MIT)
John Ousterhout (Berkeley)
Andrew Palay (ITC CMU)
Ralph Swick (MIT)
Craig Taylor (Sun)
Jeffery Vroom (Stellar)
This document does not attempt to provide the rationale or pragmatics required
to fully understand the protocol or to place it in perspective within a
complete system. Knowledge of X Version 10 will certainly aid in
understanding this document.
The protocol contains many management mechanisms that are not intended for
normal applications. Not all mechanisms are needed to build a particular user
interface. It is important to keep in mind that the protocol is intended to
provide mechanism, not policy.
This document does not attempt to define precise formats or bit encodings.
-------------------------------------------------------------------------------
SECTION 1. TERMINOLOGY
Access control list
X maintains a list of hosts from which client programs may be run. By
default, only programs on the local host may use the display, plus any
hosts specified in an initial list read by the server. This "access
control list" can be changed by clients on the local host. Some server
implementations may also implement other authorization mechanisms.
Active grab
A grab is "active" when the pointer or keyboard is actually owned by
the single grabbing client.
Ancestors
If W is an inferior of A, then A is an "ancestor" of W.
Atom
An "atom" is a unique id corresponding to a string name. Atoms are
used to identify properties, types, and selections.
Backing store
When a server maintains the contents of a window, the off-screen saved
pixels are known as a "backing store".
Bit gravity
When a window is resized, the contents of the window are not
necessarily discarded. It is possible to request the server (though no
guarantees are made) to relocate the previous contents to some region
of the window. This attraction of window contents for some location of
a window is known as "bit gravity".
Bitmap
A "bitmap" is a pixmap of depth one.
Button grabbing
Buttons on the pointer may be passively "grabbed" by a client. When
the button is pressed, the pointer is then actively grabbed by the
client.
Byte order
For image (pixmap/bitmap) data, byte order is defined by the server,
and clients with different native byte ordering must swap bytes as
necessary. For all other parts of the protocol, the byte order is
defined by the client, and the server swaps bytes as necessary.
Children
The "children" of a window are its first-level subwindows.
Client
An application program connects to the window system server by some
interprocess communication (IPC) path, such as a TCP connection or a
shared memory buffer. This program is referred to as a "client" of the
window system server. More precisely, the client is the IPC path
itself; a program with multiple paths open to the server is viewed as
multiple clients by the protocol. Resource lifetimes are controlled by
connection lifetimes, not by program lifetimes.
Clipping regions
In a graphics context, a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window. The image
defined by the bitmap or rectangles is called a "clipping region".
Color cell
An entry in a colormap is known as a "color cell". An entry contains
three values specifying red, green and blue intensities. These values
are always viewed as 16 bit unsigned numbers, with zero being minimum
intensity. The values are scaled by the server to match the display
hardware. The components of a cell are coincident with components of
other cells in DirectColor and TrueColor colormaps.
Colormap
A "colormap" consists of a set of color cells. A pixel value indexes
the color map to produce intensities to be displayed. Depending on
hardware limitations, one or more colormaps may be installed at one
time, such that windows associated with those maps display with true
colors.
Connection
The IPC path between the server and client program is known as a
"connection". A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
Containment
A window "contains" the pointer if the window is viewable and the
hotspot of the cursor is within a visible region of the window or a
visible region of one of its inferiors. The border of the window is
included as part of the window for containment. The pointer is "in" a
window if the window contains the pointer but no inferior contains the
pointer.
Coordinate system
The coordinate system has X horizontal and Y vertical, with the origin
[0, 0] at the upper left. Coordinates are discrete, and in terms of
pixels. Each window and pixmap has its own coordinate system. For a
window, the origin is at the inside upper left, inside the border.
Cursor
A "cursor" is the visible shape of the pointer on a screen. It
consists of a hot spot, a source bitmap, a shape bitmap, and a pair of
colors. The cursor defined for a window controls the visible
appearance when the pointer is in that window.
Depth
The "depth" of a window or pixmap is number of bits per pixel it has.
The depth of a gcontext is the depth of the root of the gcontext.
Device
Keyboards, mice, tablets, track-balls, button boxes, etc. are all
collectively known as input "devices". The core protocol only deals
with two devices, "the keyboard" and "the pointer".
Drawable
Both windows and pixmaps may be used as sources and destinations in
graphics operations. These are collectively known as "drawables".
However, an InputOnly window cannot be used as a source or destination
in a graphics operation.
Event
Clients are informed of information asynchronously via "events". These
events may be either asynchronously generated from devices, or
generated as side effects of client requests. Events are grouped into
types; events are never sent to a client by the server unless the
client has specificially asked to be informed of that type of event,
but other clients can force events to be sent to other clients. Events
are typically reported relative to a window.
Event mask
Events are requested relative to a window. The set of event types a
client requests relative to a window described using an "event mask".
Event sychronization
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations). The event synchronization mechanism allows synchronous
processing of device events.
Event propagation
Device-related events "propagate" from the source window to ancestor
windows until some client has expressed interest in handling that type
of event, or until the event is discarded explicitly.
Event source
The smallest window containing the pointer is the "source" of a device
related event.
Exposure event
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured. "Exposure" events are sent to
clients to inform them when contents of regions of windows have been
lost.
Extension
Named "extensions" to the core protocol can be defined to extend the
system. Extension to output requests, resources, and event types are
all possible, and expected.
Font
A "font" is an array of glyphs (typically characters). The protocol
does no translation or interpretation of character sets. The client
simply indicates values used to index the glyph array. A font contains
additional metric information to determine inter-glyph and inter-line
spacing.
Glyph
A "glyph" is an image, typically of a character, in a font.
Grab
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be "grabbed" for exclusive use by a client. In general,
these facilities are not intended to be used by normal applications,
but are intended for various input and window managers to implement
various styles of user interfaces.
Graphics context
Various information for graphics output is stored in "GC"'s, such as
foreground pixel, background pixel, line width, clipping region, etc.
Hotspot
A cursor has an associated "hot spot" which defines a point in the
cursor that corresponds to the coordinates reported for the pointer.
Identifier
Each resource has an "identifier", a unique value associated with it
that clients use to name the resource. An identifier can be used over
any connection to name the resource.
Inferiors
The "inferiors" of a window are all of the subwindows nested below it:
the children, the children's children, etc.
Input focus
The "input focus" is nominally where keyboard input goes. Keyboard
events are by default sent to the client expressing interest on the
window the pointer is in. This is said to be a "real estate driven"
input focus. It is also possible to attach the keyboard input to a
specific window; events will then be sent to the appropriate client
independent of the pointer position.
Input manager
Control over keyboard input is typically provided by an "input manager"
client.
InputOnly window
A window that cannot be used for graphics requests. InputOnly windows
are "invisible", and can be used to control such things as cursors,
input event generation, and grabbing.
InputOutput window
The "normal" kind of opaque window, used for both input and output.
Key grabbing
Keys on the keyboard may be passively "grabbed" by a client. When the
key is pressed, the keyboard is then actively grabbed by the client.
Keyboard grabbing
A client can actively "grab" control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
Mapping
A window is said to be "mapped" if a map call has been performed on it.
Unmapped windows are never viewable or visible.
Modifier keys
Shift, Control, Meta, Super, Hyper, ALT, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called "modifier" keys.
Obscures
Window A "obscures" window B if both are viewable InputOutput windows
and A is higher in the global stacking order, and the rectangle defined
by the outside edges of A intersects the rectangle defined by the
outside edges of B. Note the (fine) distinction with "occludes". Also
note that window borders are included in the calculation.
Occludes
Window A "occludes" window B if both are mapped and A is higher in the
global stacking order, and the rectangle defined by the outside edges
of A intersects the rectangle defined by the outside edges of B. Note
the (fine) distinction with "obscures". Also note that window borders
are included in the calculation.
Padding
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries. This
increases ease of portability to some machine architectures.
Parent window
If C is a child of P, then P is the "parent" of C.
Passive grab
Grabbing a key or button is a "passive" grab. The grab activates when
the key or button is actually pressed.
Pixel value
A "pixel" is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap. For a window, a pixel value indexes
a colormap to derive an actual color to be displayed.
Pixmap
A "pixmap" is a three dimensional array of bits. A pixmap is normally
thought of as a two dimensional array of pixels, where each pixel can
be a value from 0 to (2↑N)-1, where N is the depth (z axis) of the
pixmap. A pixmap can also be thought of as a stack of N bitmaps.
Plane mask
Graphics operations can be restricted to only affect a subset of bit
planes of a destination. A "plane mask" is a bit mask describing which
planes are to be modified, and is stored in a graphics context.
Pointer
The "pointer" is the pointing device attached to the cursor, and
tracked on the screens.
Pointer grabbing
A client can actively "grab" control of the pointer, and button and
motion events will be sent to that client rather than the client the
events would normally have been sent to.
Pointing device
A "pointing device" is typically a mouse or tablet, or some other
device with effective dimensional motion. There is only one visible
cursor is defined by the core protocol, and it tracks whatever pointing
device is attached as the pointer.
Property
Windows may have associated "properties", consisting of a name, a type,
a data format, and some data. The protocol places no interpretation on
properties, they are intended as a general-purpose naming mechanism for
clients. For example, clients might share information such as resize
hints, program names, and icon formats with a window manager via
properties.
Property list
The "property list" of a window is the list of properties that have
been defined for the window.
Redirecting control
Window managers (or client programs) may wish to enforce window layout
policy in various ways. When a client attempts to change the size or
position of a window, the operation may be "redirected" to a specified
client, rather than the operation actually being performed.
Reply
Information requested by a client program is sent back to the client
with a "reply". Both events and replys are multipexed on the same
connection. Most requests do not generate replies.
Request
A command to the server is called a "request". It is a single block of
data sent over a connection.
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as "resources". They all have unique identifiers associated with
them for naming purposes. The lifetime of a resource is bounded by the
lifetime of the connection over which the resource was created.
Root
The "root" of a pixmap or gcontext is the same as the root of whatever
drawable was used when the pixmap or gcontext was created. The "root"
of a window is the root window under which the window was created.
Root window
Each screen has a "root window" covering it. It cannot be reconfigured
or unmapped, but otherwise acts as a full fledged window. A root
window has no parent.
Save set
The "save set" of a client is a list of other client's windows which,
if they are inferiors of one of the client's windows at connection
close, should not be destroyed, and which should be remapped if it is
unmapped. Save sets are typically used by window managers to avoid
lost windows if the manager should terminate abnormally.
Screen
A server may provide several independent "screens", which typically
have physically independent monitors. This would be the expected
configuration when there is only a single keyboard and pointer shared
among the screens.
Server
The "server" provides the basic windowing mechanism. It handles IPC
connections from clients, demultipexes graphics requests onto the
screens, and multiplexes input back to the appropriate clients.
Server grabbing
The server can be "grabbed" by a single client for exclusive use. This
prevents processing of any requests from other client connections until
the grab is complete. This is typically only a transient state for
such things as rubber-banding and pop-up menus, or to execute requests
indivisibly.
Sibling
Children of the same parent window are known as "sibling" windows.
Stacking order
Sibling windows may "stack" on top of each other. Windows above both
obscure and occlude lower windows. This is similar to paper on a desk.
The relationship between sibling windows is known as the "stacking
order".
Stipple
A "stipple pattern" is a bitmap that is used to tile a region to serve
as an additional clip mask for a fill operation with the foreground
color.
Tile
A pixmap can be replicated in two dimensions to "tile" a region. The
pixmap itself is also known as a "tile".
Timestamp
A time value, expressed in milliseconds, typically since the last
server reset. Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T, and half of the
timestamp space as being later in time than T. One timestamp value
(named CurrentTime) is never generated by the server; this value is
reserved for use in requests to represent the current server time.
Type
A type is an arbitrary atom used to identify the interpretation of
property data. Types are completely uninterpreted by the server; they
are solely for the benefit of clients.
Unviewable
A window is "unviewable" if it is mapped but some ancestor is unmapped.
Viewable
A window is "viewable" if it and all of its ancestors are mapped. This
does not imply that any portion of the window is actually visible.
Visible
A region of a window is "visible" if someone looking at the screen can
actually "see" it: the window is viewable and the region is not
occluded by any other window.
Window gravity
When windows are resized, subwindows may be repositioned automatically
relative to some position in the window. This attraction of a
subwindow to some part of its parent is known as "window gravity".
Window manager
Manipulation of windows on the screen, and much of the user interface
(policy) is typically provided by a "window manager" client.
XYFormat
The data for a pixmap is said to be in "XYFormat" if it is organized as
a set of bitmaps representing individual bit planes.
ZFormat
The data for a pixmap is said to be in "ZFormat" if it is organized as
a set of pixel values in scanline order.
SECTION 2. PROTOCOL FORMATS
Request Format
Every request contains an 8-bit "major" opcode, and a 16-bit length field
expressed in units of 4 bytes. Every request consists of 4 bytes of header
(containing the major opcode, the length field, and a data byte) followed by
zero or more additional bytes of data; the length field defines the total
length of the request, including the header. The length field in a request
must equal the minimum length required to contain the request; if the
specified length is smaller or larger than the required length, an error is
generated. Unused bytes in a request are not required to be zero. Major
opcodes 128 through 255 are reserved for extensions. Extensions are intended
to contain multiple requests, so extension requests typically have an
additional minor opcode encoded in the "spare" data byte in the request
header, but the placement and interpretation of this minor opcode, and all
other fields in extension requests, are not defined by the core protocol.
Every request is implicitly assigned a sequence number, starting with one,
used in replies, errors, and events.
Reply Format
Every reply contains a 32-bit length field expressed in units of 4 bytes.
Every reply consists of 32 bytes, followed by zero or more additional bytes of
data, as specified in the length field. Unused bytes within a reply are not
guaranteed to be zero. Every reply also contains the least significant 16
bits of the sequence number of the corresponding request.
Error Format
Error reports are 32 bytes long. Every error includes an 8-bit error code.
Error codes 128 through 255 are reserved for extensions. Every error also
includes the major and minor opcodes of the failed request, and the least
significant 16 bits of the sequence number of the request. For the following
errors (see Section 5), the failing resource id is also returned: Colormap,
Cursor, Drawable, Font, GContext, IDChoice, Pixmap, and Window. For Atom
errors, the failing atom is returned. For Value errors, the failing value is
returned. Other core errors return no additional data. Unused bytes within
an error are not guaranteed to be zero.
Event Format
Events are 32 bytes long. Unused bytes within an event are not guaranteed to
be zero. Every event contains an 8-bit type code. The most significant bit
in this code is set if the event was generated from a SendEvent request.
Event codes 64 through 127 are reserved for extensions, although the core
protocol does not define a mechanism for selecting interest in such events.
Every core event (with the exception of KeymapNotify) also contains the least
significant 16 bits of the sequence number of the last request issued by the
client that was (or is currently being) processed by the server.
SECTION 3. SYNTAX
The syntax {...} encloses a set of alternatives.
The syntax [...] encloses a set of structure components.
In general, TYPEs are in upper case and AlternativeValues are capitalized.
Requests in Section 10 are described in the following format:
RequestName
arg1: type1
...
argN: typeN
=>
result1: type1
...
resultM: typeM
Errors: kind1, ..., kindK
Description.
If no => is present in the description, then the request has no reply (it is
asynchronous), although errors may still be reported.
Events in Section 12 are described in the following format:
EventName
value1: type1
...
valueN: typeN
Description.
SECTION 4. COMMON TYPES
LISTofFOO
A type name of the form LISTofFOO means a counted list of elements of type
FOO; the size of the length field may vary (it is not necessarily the same
size as a FOO), in some cases may be implicit, and is not fully specified in
this document.
BITMASK and LISTofVALUE
The types BITMASK and LISTofVALUE are somewhat special. Various requests
contain arguments of the form:
value-mask: BITMASK
value-list: LISTofVALUE
used to allow the client to specify a subset of a heterogeneous collection of
"optional" arguments. The value-mask specifies which arguments are to be
provided; each such argument is assigned a unique bit position. The
representation of the BITMASK will typically contain more bits than there are
defined arguments; unused bits in the value-mask must be zero (or the server
generates a Value error). The value-list contains one value for each one bit
in the mask, from least to most significant bit in the mask. Each value is
represented with 4 bytes, but the actual value occupies only the least
significant bytes as required; the values of the unused bytes do not matter.
Or Types
A type of the form "T1 or ... or Tn" means the union of the indicated types; a
single-element type is given as the element without enclosing braces.
DEVICE: 32-bit id (<class,model,manufacturer,unit> 8 bits each)
WINDOW: 32-bit id
PIXMAP: 32-bit id
CURSOR: 32-bit id
FONT: 32-bit id
GCONTEXT: 32-bit id
COLORMAP: 32-bit id
DRAWABLE: WINDOW or PIXMAP
ATOM: 32-bit id (top 3 bits guaranteed to be zero)
VISUALID: 32-bit id (top 3 bits guaranteed to be zero)
VALUE: 32-bit quantity (used only in LISTofVALUE)
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer
TIMESTAMP: CARD32
BITGRAVITY: {Forget, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
WINGRAVITY: {Unmap, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
BOOL: {True, False}
EVENT: {KeyPress, KeyRelease,
OwnerGrabButton,
ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
Exposure, VisibilityChange,
StructureNotify, ResizeRedirect,
SubstructureNotify, SubstructureRedirect,
FocusChange,
PropertyChange, ColormapChange,
KeymapState}
POINTEREVENT: {ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
KeymapState}
DEVICEEVENT: {KeyPress, KeyRelease,
ButtonPress, ButtonRelease,
PointerMotion,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion}
KEYCODE: CARD8
BUTTON: CARD8
KEYMASK: {Shift, CapsLock, Control, Mod1, Mod2, Mod3, Mod4, Mod5}
BUTMASK: {Button1, Button2, Button3, Button4, Button5}
KEYBUTMASK: KEYMASK or BUTMASK
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B: [byte1, byte2: CARD8]
POINT: [x, y: INT16]
RECTANGLE: [x, y: INT16,
width, height: CARD16]
ARC: [x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOST: [family: {Internet, NS, ECMA, Datakit, DECnet}
address: LISTofCARD8]
The [x,y] coordinates of a RECTANGLE specify the upper left corner.
The primary interpretation of "large" characters in a STRING16 is that they
are composed of two bytes used to index a 2-D matrix; hence the use of CHAR2B
rather than CARD16. This corresponds to the JIS/ISO method of indexing
two-byte characters. It is expected that most "large" fonts will be defined
with two-byte matrix indexing. For large fonts constructed with linear
indexing, a CHAR2B can be interpreted as a 16-bit number by treating byte1 as
the most significant byte; this means that clients should always transmit such
16-bit character values most significant byte first, as the server will never
byte-swap CHAR2B quantities.
The length, format, and interpretation of a HOST address are specific to the
family.
SECTION 5. ERRORS
In general, when a request terminates with an error, the request has no side
effects (i.e., there is no partial execution). The only requests for which
this is not true are ChangeWindowAttributes, ChangeGC, PolyText8, PolyText16,
FreeColors, StoreColors, and ChangeKeyboardControl.
The following error codes can be returned by the various requests:
Access
An attempt to grab a key/button combination already grabbed by another
client.
An attempt to free a colormap entry not allocated by the client.
An attempt to store into a read-only or an unallocated colormap entry.
An attempt to modify the access control list from other than the local
(or otherwise authorized) host.
An attempt to select an event type, that at most one client can
select at a time, when another client has already selected it.
Alloc
The server failed to allocate the requested resource.
Note that this only covers allocation errors at a very coarse level,
and is not intended to (nor can it in practice hope to) cover all cases
of a server running out of allocation space in the middle of service.
The semantics when a server runs out of allocation space are left
unspecified.
Atom
A value for an ATOM argument does not name a defined ATOM.
Colormap
A value for a COLORMAP argument does not name a defined COLORMAP.
Cursor
A value for a CURSOR argument does not name a defined CURSOR.
Drawable
A value for a DRAWABLE argument does not name a defined WINDOW or
PIXMAP.
Font
A value for a FONT or <FONT or GCONTEXT> argument does not name a
defined FONT.
GContext
A value for a GCONTEXT argument does not name a defined GCONTEXT.
IDChoice
The value chosen for a resource identifier is either not included
in the range assigned to the client, or is already in use.
Implementation
The server does not implement some aspect of the request. A server
which generates this error for a core request is deficient. As such,
this error is not listed for any of the requests, but clients should be
prepared to receive such errors, and handle or discard them.
Length
The length of a request is shorter or longer than that required
to minimally contain the arguments.
Match
An InputOnly window is used as a DRAWABLE.
Some argument (or pair of arguments) has the correct type and range,
but fails to "match" in some other way required by the request.
Name
A font or color of the specified name does not exist.
Pixmap
A value for a PIXMAP argument does not name a defined PIXMAP.
Property
The requested property does not exist for the specified window.
Request
The major or minor opcode does not specify a valid request.
Value
Some numeric value falls outside the range of values accepted by the
request. Unless a specific range is specified for an argument, the
full range defined by the argument's type is accepted. Any argument
defined as a set of alternatives can generate this error.
Window
A value for a WINDOW argument does not name a defined WINDOW.
Note: the Atom, Colormap, Cursor, Drawable, Font, GContext, Pixmap, and Window
errors are also used when the argument type is extended by union with a set of
fixed alternatives, e.g., <Window or PointerRoot or None>.
∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 4 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082815.9.RWS@KILLINGTON.LCS.MIT.EDU>
QueryFont
font: FONT or GCONTEXT
=>
font-info: FONTINFO
char-infos: LISTofCHARINFO
where
FONTINFO: [draw-direction: {LeftToRight, RightToLeft}
min-char-or-byte2, max-char-or-byte2: CARD16
min-byte1, max-byte1: CARD8
all-chars-exist: BOOL
default-char: CARD16
min-bounds: CHARINFO
max-bounds: CHARINFO
font-ascent: INT16
font-descent: INT16
properties: LISTofFONTPROP]
FONTPROP: [name: ATOM
value: INT32 or CARD32]
CHARINFO: [left-side-bearing: INT16
right-side-bearing: INT16
character-width: INT16
ascent: INT16
descent: INT16
attributes: CARD16]
Errors: Font
Returns logical information about a font.
The draw-direction is essentially just a hint, indicating whether most
char-infos have a positive (LeftToRight) or a negative (RightToLeft)
character-width metric. The core protocol defines no support for
vertical text.
If min-byte1 and max-byte1 are both zero, then min-char-or-byte2
specifies the linear character index corresponding to the first elementb
of char-infos, and max-char-or-byte2 specifies the linear character
index of the last element. If either min-byte1 or max-byte1 are
non-zero, then both min-char-or-byte2 and max-char-or-byte2 will be
less than 256, and the two-byte character index values corresponding to
char-infos element N (counting from 0) are
byte1 = N/D + min-byte1
byte2 = N\D + min-char-or-byte2
where
D = max-char-or-byte2 - min-char-or-byte2 + 1
/ = integer division
\ = integer modulus
If char-infos has length zero, then min-bounds and max-bounds will be
identical, and the effective char-infos is one filled with this
char-info, of length
L = D * (max-byte1 - min-byte1 + 1)
That is, all glyphs in the specified linear or matrix range have the
same information, as given by min-bounds (and max-bounds). If
all-chars-exist is True, then all characters in char-infos have
non-zero bounding boxes.
The default-char specifies the character that will be used when an
undefined or non-existent character is used. Note that default-char is
a CARD16 (not CHAR2B); for a font using two-byte matrix format, the
default-char has byte1 in the most significant byte, and byte2 in the
least significant byte. If the default-char itself specifies an
undefined or non-existent character, then no printing is performed for
an undefined or non-existent character.
The min-bounds and max-bounds contain the minimum and maximum values of
each individual CHARINFO component over all char-infos (ignoring
non-existent characters). The bounding box of the font, i.e., the
smallest rectangle enclosing the shape obtained by superimposing all
characters at the same origin [x,y], has its upper left coordinate at
[x + min-bounds.left-side-bearing, y - max-bounds.ascent]
with a width of
max-bounds.right-side-bearing - min-bounds.left-side-bearing
and a height of
max-bounds.ascent + max-bounds.descent
The font-ascent is the logical extent of the font above the baseline,
for determining line spacing. Specific characters may extend beyond
this. The font-descent is the logical extent of the font at or below
the baseline, for determining line spacing. Specific characters may
extend beyond this. If the baseline is at Y-coordinate y, then the
logical extent of the font is inclusive between the Y-coordinate values
(y - font-ascent) and (y + font-descent - 1).
A font is not guaranteed to have any properties. Whether a property
value is signed or unsigned must be derived from a priori knowledge of
the property. When possible, fonts should have at least the following
properties (note that the trailing colon is not part of the name, and
that upper/lower case matters).
MinSpace: CARD32
The minimum interword spacing, in pixels.
NormSpace: CARD32
The normal interword spacing, in pixels.
MaxSpace: CARD32
The maximum interword spacing, in pixels.
EndSpace: CARD32
The additional spacing at the end of sentences, in pixels.
SuperscriptX: INT32
SuperscriptY: INT32
Offsets from the character origin where superscripts should begin,
in pixels. If the origin is at [x,y], then superscripts should
begin at [x + SuperscriptX, y - SuperscriptY].
SubscriptX: INT32
SubscriptY: INT32
Offsets from the character origin where subscripts should begin, in
pixels. If the origin is at [x,y], then subscripts should begin at
[x + SubscriptX, y + SubscriptY].
UnderlinePosition: INT32
Y offset from the baseline to the top of an underline, in pixels.
If the baseline is Y-coordinate y, then the top of the underline is
at (y + UnderlinePosition).
UnderlineThickness: CARD32
Thickness of the underline, in pixels.
StrikeoutAscent: INT32
StrikeoutDescent: INT32
Vertical extents for boxing or voiding characters, in pixels. If
the baseline is at Y-coordinate y, then the top of the strikeout
box is at (y - StrikeoutAscent), and the height of the box is
(StrikeoutAscent + StrikeoutDescent).
ItalicAngle: INT32
The angle of characters in the font, in degrees scaled by 64,
relative to the three-oclock position from the character origin,
with positive indicating counterclockwise motion (as in Arc
requests).
XHeight: INT32
"1 ex" as in TeX, but expressed in units of pixels. Often the
height of lowercase x.
QuadWidth: INT32
"1 em" as in TeX, but expressed in units of pixels. Often the
width of the digits 0-9.
Weight: CARD32
The weight or boldness of the font, expressed as a value between 0
and 1000.
PointSize: CARD32
The point size, expressed in 1/10ths, of this font at the ideal
resolution. There are 72.27 points to the inch.
Resolution: CARD32
The number of pixels per point, expressed in 1/100ths, at which
this font was created.
For a character origin at [x,y], the bounding box of a character, i.e.,
the smallest rectangle enclosing the character's shape, described in
terms of CHARINFO components, is a rectangle with its upper left corner
at
[x + left-side-bearing, y - ascent]
with a width of
right-side-bearing - left-side-bearing
and a height of
ascent + descent
and the origin for the next character is defined to be
[x + character-width, y]
Note that the baseline is logically viewed as being just below
non-descending characters (when descent is zero, only pixels with
Y-coordinates less than y are drawn), and that the origin is logically
viewed as being coincident with the left edge of a non-kerned character
(when left-side-bearing is zero, no pixels with X-coordinate less than
x are drawn).
Note that CHARINFO metric values can be negative.
A non-existent character is represented with all CHARINFO components
zero.
The interpretation of the per-character attributes field is undefined
by the core protocol.
QueryTextExtents
font: FONT or GCONTEXT
items: STRING16
=>
draw-direction: {LeftToRight, RightToLeft}
font-ascent: INT16
font-descent: INT16
overall-ascent: INT16
overall-descent: INT16
overall-width: INT32
overall-left: INT32
overall-right: INT32
Errors: Font
Returns the logical extents of the specified string of characters in
the specified font. Draw-direction, font-ascent, and font-descent are
as described in QueryFont. Overall-ascent is the maximum of the ascent
metrics of all characters in the string, and overall-descent is the
maximum of the descent metrics. Overall-width is the sum of the
character-width metrics of all characters in the string. For each
character in the string, let W be the sum of the character-width
metrics of all characters preceding it in the string, let L be the
left-side-bearing metric of the character plus W, and let R be the
right-side-bearing metric of the character plus W. Overall-left is the
minimum L of all characters in the string, and overall-right is the
maximum R.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
If the font has no defined default-char, then undefined characters in
the string are taken to have all zero metrics.
ListFonts
pattern: STRING8
max-names: CARD16
=>
names: LISTofSTRING8
Returns a list of length at most max-names, of names of fonts matching
the pattern. The pattern should use the ASCII encoding, and
upper/lower case does not matter. In the pattern, the '?' character
(octal value 77) will match any single character, and the character '*'
(octal value 52) will match any number of characters. The returned
names are in lower case.
ListFontsWithInfo
pattern: STRING8
max-names: CARD16
=>
fonts: LISTofFONTDATA
where
FONTDATA: [name: STRING8
info: FONTINFO]
FONTINFO: <same type definition as in QueryFont>
Like ListFonts, but also returns information about each font. The
information returned for each font is identical to what QueryFont would
return (except that the per-character metrics are not returned).
SetFontPath
path: LISTofSTRING8
Errors: Value
Defines the search path for font lookup. There is only one search path
per server, not one per client. The interpretation of the strings is
operating system dependent, but they are intended to specify
directories to be searched in the order listed.
Setting the path to the empty list restores the default path defined
for the server.
As a side-effect of executing this request, the server is guaranteed to
flush all cached information about fonts for which there currently are
no explicit resource ids allocated.
The meaning of an error from this request is system specific.
GetFontPath
=>
path: LISTofSTRING8
Returns the current search path for fonts.
CreatePixmap
pid: PIXMAP
drawable: DRAWABLE
depth: CARD8
width, height: CARD16
Errors: IDChoice, Drawable, Value, Alloc
Creates a pixmap, and assigns the identifier pid to it. Width and
height must be non-zero. Depth must be one of the depths supported by
root of the specified drawable. The initial contents of the pixmap are
undefined.
It is legal to pass an InputOnly window as a drawable to this request.
FreePixmap
pixmap: PIXMAP
Errors: Pixmap
Deletes the association between the resource id and the pixmap. The
pixmap storage will be freed when no other resource references it.
CreateGC
cid: GCONTEXT
drawable: DRAWABLE
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Drawable, Pixmap, Font, Match, Value, Alloc
Creates a graphics context, and assigns the identifier cid to it. The
gcontext can be used with any destination drawable having the same root
and depth as the specified drawable.
The value-mask and value-list specify which components are to be
explicitly initialized. The context components are:
alu-function: {Clear, And, AndReverse, Copy, AndInverted, Noop,
Xor, Or, Nor, Equiv, Invert, OrReverse,
CopyInverted, OrInverted, Nand, Set}
plane-mask: CARD32
foreground: CARD32
background: CARD32
line-width: CARD16
line-style: {Solid, OnOffDash, DoubleDash}
cap-style: {NotLast, Butt, Round, Projecting}
join-style: {Miter, Round, Bevel}
fill-style: {Solid, Tiled, OpaqueStippled, Stippled}
fill-rule: {EvenOdd, Winding}
arc-mode: {Chord, PieSlice}
tile: PIXMAP
stipple: PIXMAP
tile-stipple-x-origin: INT16
tile-stipple-y-origin: INT16
font: FONT
subwindow-mode: {ClipByChildren, IncludeInferiors}
graphics-exposures: BOOL
clip-x-origin: INT16
clip-y-origin: INT16
clip-mask: PIXMAP or None
dash-offset: CARD16
dash-list: CARD8
In graphics operations, given a source and destination pixel, the
result is computed bitwise on corresponding bits of the pixels. That
is, a boolean operation is performed in each bit plane. The plane-mask
restricts the operation to a subset of planes. That is, the result is
((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
Range checking is not performed on the values for foreground,
background, or plane-mask; they are simply truncated to the appropriate
number of bits.
The meanings of the alu-functions are:
Clear 0
And src AND dst
AndReverse src AND (NOT dst)
Copy src
AndInverted (NOT src) AND dst
NoOp dst
Xor src XOR dst
Or src OR dst
Nor (NOT src) AND (NOT dst)
Equiv (NOT src) XOR dst
Invert NOT dst
OrReverse src OR (NOT dst)
CopyInverted NOT src
OrInverted (NOT src) OR dst
NAnd (NOT src) OR (NOT dst)
Set 1
Line-width is measured in pixels and can be greater than or equal to
one (a "wide" line) or the special value zero (a "thin" line).
Wide lines are drawn centered on the path described by the graphics
request. Unless otherwise specified by the join or cap style, the
bounding box of a wide line with endpoints [x1, y1], [x2, y2], and
width w is a rectangle with vertices at the following real coordinates:
[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
where sn is the sine of the angle of the line and cs is the cosine of
the angle of the line. A pixel is part of the line (and hence drawn)
if the center of the pixel is fully inside the bounding box (which is
viewed as having infinitely thin edges). If the center of the pixel is
exactly on the bounding box, it is part of the line if and only if the
interior is immediately to its right (x increasing direction). Pixels
with centers on a horizontal edge are a special case and are part of
the line if and only if the interior is immediately below (y increasing
direction). Note that this description is a mathematical model
describing the pixels that are drawn for a wide line and does not imply
that trigonometry is required to implement such a model. Real or fixed
point arithmetic is recommended for computing the corners of the line
endpoints for lines greater than one pixel in width.
Thin lines (zero line-width) are "one pixel wide" lines drawn using an
unspecified, device dependent algorithm (for example, Bresenham).
There are only two constraints on this algorithm. First, if a line is
drawn unclipped from [x1,y1] to [x2,y2] and another line is drawn
unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy], then a point [x,y] is
touched by drawing the first line if and only if the point [x+dx,y+dy]
is touched by drawing the second line. Second, the effective set of
points comprising a line cannot be affected by clipping; that is, a
point is touched in a clipped line if and only if the point lies inside
the clipping region and the point would be touched by the line when
drawn unclipped.
Note that a wide line drawn from [x1,y1] to [x2,y2] always draws the
same pixels as a wide line drawn from [x2,y2] to [x1,y1], not counting
cap and join styles, but this property is not guaranteed for thin
lines. Also note that "jags" in adjacent wide lines will always line
up properly, but this property is not guaranteed for thin lines. A
line-width of zero differs from a line-width of one in which pixels are
drawn. In general, drawing a thin line will be faster than drawing a
wide line of width one, but thin lines may not mix well aesthetically
with wide lines because of the different drawing algorithms. If it is
desirable to obtain precise and uniform results across all displays, a
client should always use a line-width of one, rather than a line-width
of zero.
The line-style defines which segments of a line are drawn:
Solid: the full path of the line is drawn
DoubleDash: the full path of the line is drawn, but the segments
defined by the even dashes are filled differently than
the segments defined by the odd dashes (see fill-style)
OnOffDash: only the segments defined by the even dashes are drawn,
and cap-style applies to each individual segment (except
NotLast is treated as Butt for internal caps)
The cap-style defines how the endpoints of a path are drawn:
NotLast: equivalent to Butt, except that for a line-width
of zero or one the final endpoint is not drawn
Butt: square at the endpoint, with no projection beyond
Round: a circular arc with diameter equal to the line-width,
centered on the endpoint; equivalent to Butt for line-width
zero or one
Projecting: square at the end, but the path continues beyond the
endpoint for a distance equal to half the line-width;
equivalent to Butt for line-width zero or one
The join-style defines how corners are drawn for wide lines:
Miter: the outer edges of the two lines extend to meet at an
angle
Round: a circular arc with diameter equal to the line-width,
centered on the joinpoint
Bevel: Butt endpoint styles, and then the triangular "notch" filled
The tile/stipple and clip origins are interpreted relative to the
origin of whatever destination drawable is specified in a graphics
request.
The tile pixmap must have the same root and depth as the gcontext (else
a Match error). The stipple pixmap must have depth one, and must have
the same root as the gcontext (else a Match error). For stipple
operations, the stipple pattern is tiled in a single plane, and acts as
an additional clip mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling, although some sizes may be
faster to use than others.
The fill-style defines the contents of the source for line, text, and
fill requests. For all text and fill requests (PolyText8, PolyText16,
PolyFillRectangle, FillPoly, PolyFillArc), for line requests (PolyLine,
PolySegment, PolyRectangle, PolyArc) with line-style Solid, and for the
even dashes for line requests with line-style OnOffDash or DoubleDash:
Solid: foreground
Tiled: tile
OpaqueStippled: a tile with the same width and height as stipple,
but with background everywhere stipple has a zero
and with foreground everywhere stipple has a one
Stippled: foreground masked by stipple
For the odd dashes for line requests with line-style DoubleDash:
Solid: background
Tiled: same as for even dashes
OpaqueStippled: same as for even dashes
Stippled: background masked by stipple
The dash-list value allowed here is actually a simplified form of the
more general patterns that can be set with SetDashes. Specifying a
value of N here is equivalent to specifying the two element list [N, N]
in SetDashes. The value must be non-zero. The meaning of dash-offset
and dash-list are explained in the SetDashes request.
The clip-mask restricts writes to the destination drawable; only pixels
where the clip-mask has a one bit are drawn. It affects all graphics
requests. The clip-mask does not clip sources. The clip-mask origin
is interpreted relative to the origin of whatever destination drawable
is specified in a graphics request. If a pixmap is specified as the
clip-mask, it must have depth one and have the same root as the
gcontext (else a Match error). The clip-mask can also be set with the
SetClipRectangles request.
For ClipByChildren, both source and destination windows are
additionally clipped by all viewable InputOutput children. For
IncludeInferiors, neither source nor destination window is clipped by
inferiors; this will result in drawing through subwindow boundaries.
The use of IncludeInferiors on a window of one depth with mapped
inferiors of differing depth is not illegal, but the semantics is
undefined by the core protocol.
The fill-rule defines what pixels are inside (i.e., are drawn) for
paths given in FillPoly requests. EvenOdd means a point is inside if
an infinite ray with the point as origin crosses the path an odd number
of times. For Winding, a point is inside if an infinite ray with the
point as origin crosses an unequal number of clockwise and
counterclockwise directed path segments. For both rules, a "point" is
infinitely small, and the path is an infinitely thin line. A pixel is
inside if the center point of the pixel is inside and the center point
is not on the boundary. If the center point is on the boundary, the
pixel is inside if and only if the polygon interior is immediately to
its right (x increasing direction). Pixels with centers along a
horizontal edge are a special case and are inside if and only if the
polygon interior is immediately below (y increasing direction).
The arc-mode controls filling in the PolyFillArc request.
The graphics-exposures flag controls GraphicsExposure event generation
for CopyArea and CopyPlane requests (and any similar requests defined
by extensions).
The default component values are:
function: Copy
plane-mask: all ones
foreground: 0
background: 1
line-width: 0
line-style: Solid
cap-style: Butt
join-style: Miter
fill-style: Solid
full-rule: EvenOdd
arc-mode: PieSlice
tile: pixmap of unspecified size filled with foreground pixel
(i.e., client specified pixel if any, else 0)
stipple: pixmap of unspecified size filled with ones
tile-stipple-x-origin: 0
tile-stipple-y-origin: 0
font: <implementation dependent>
subwindow-mode: ClipByChildren
graphics-exposures: True
clip-x-origin: 0
clip-y-origin: 0
clip-mask: None
dash-offset: 0
dash-list: 4 (i.e., the list [4, 4])
Storing a pixmap in a gcontext might or might not result in a copy
being made. If the pixmap is later used as the destination for a
graphics request, the change might or might not be reflected in the
gcontext. If the pixmap is used simultaneously in a graphics request
as both a destination and as a tile or stipple, the results are not
defined.
It is quite likely that some amount of gcontext information will be
cached in display hardware, and that such hardware can only cache a
small number of gcontexts. Given the number and complexity of
components, clients should view switching between gcontexts with nearly
identical state as significantly more expensive than making minor
changes to a single gcontext.
ChangeGC
gc: GCONTEXT
value-mask: BITMASK
value-list: LISTofVALUE
Errors: GContext, Pixmap, Font, Match, Value, Alloc
Changes components in gc. The value-mask and value-list specify which
components are to be changed. The values and restrictions are the same
as for CreateGC.
Changing the clip-mask also overrides any previous SetClipRectangles
request on the context. Changing the dash-offset or dash-list
overrides any previous SetDashes request on the context.
The order in which components are verified and altered is server
dependent. If an error is generated, a subset of the components may
have been altered.
CopyGC
src-gc, dst-gc: GCONTEXT
value-mask: BITMASK
Errors: GContext, Value, Match, Alloc
Copies components from src-gc to dst-gc. The value-mask specifies
which components to copy, as for CreateGC. The two gcontexts must have
the same root and the same depth (else a Match error).
SetDashes
gc: GCONTEXT
dash-offset: CARD16
dash-list: LISTofCARD8
Errors: GContext, Value, Alloc
Sets the dash-offset and dash-list in gc for dashed line styles. The
initial and alternating elements of the dash-list are the "even"
dashes, the others are the "odd" dashes. All of the elements must be
non-zero. The dash-offset defines the phase of the pattern, specifying
how many pixels into the dash-list the pattern should actually begin in
any single graphics request. Dashing is continuous through path
segments combined with a join-style, but is reset to the dash-offset
each time a cap-style is applied.
SetClipRectangles
gc: GCONTEXT
clip-x-origin, clip-y-origin: INT16
rectangles: LISTofRECTANGLE
ordering: {UnSorted, YSorted, YXSorted, YXBanded}
Errors: GContext, Value, Alloc, Match
Changes clip-mask in gc to the specified list of rectangles and sets
the clip origin. Output will be clipped to remain contained within the
rectangles. The clip origin is interpreted relative to the origin of
whatever destination drawable is specified in a graphics request. The
rectangle coordinates are interpreted relative to the clip origin. The
rectangles should be non-intersecting, or graphics results will be
undefined.
If known by the client, ordering relations on the rectangles can be
specified with the ordering argument; this may provide faster operation
by the server. If an incorrect ordering is specified, the server may
generate a Match error, but is not required to do so; if no error is
generated, the graphics results are undefined. UnSorted means the
rectangles are in arbitrary order. YSorted means that the rectangles
are non-decreasing in their Y origin. YXSorted additionally constrains
YSorted order in that all rectangles with an equal Y origin are
non-decreasing in their X origin. YXBanded additionally constrains
YXSorted by requiring that for every possible Y scanline, all
rectangles that include that scanline have identical Y origins and Y
extents.
FreeGC
gc: GCONTEXT
Errors: GContext
Deletes the association between the resource id and the gcontext, and
destroys the gcontext.
ClearToBackground
window: WINDOW
x, y: INT16
width, height: CARD16
exposures: BOOL
Errors: Window, Value, Match
The x and y coordinates are relative to the window's origin, and
specify the upper left corner of the rectangle. If width is zero, it
is replaced with the current width of the window minus x. If height is
zero, it is replaced with the current height of the window minus y. If
the window has a defined background tile, the rectangle is tiled with a
plane-mask of all ones and alu-function of Copy. If the window has
background None, the contents of the window are not changed. In either
case, if exposures is True, then one or more exposure events are
generated for regions of the rectangle that are either visible or are
being retained in a backing store.
It is a Match error to use an InputOnly window in this request.
CopyArea
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
Errors: Drawable, GContext, Match
Combines the specified rectangle of src-drawable with the specified
rectangle of dst-drawable. The src-x and src-y coordinates are
relative to src-drawable's origin, dst-x and dst-y are relative to
dst-drawable's origin, each pair specifying the upper left corner of
the rectangle. Src-drawable must have the same root and the same depth
as dst-drawable (else a Match error).
If regions of the source rectangle are obscured and have not been
retained by the server, or if regions outside the boundaries of the
source drawable are specified, then the following occurs. If the
dst-drawable is a window with a background of other than None, the
corresponding regions of the destination are tiled (with plane-mask of
all ones and alu-function Copy) with that background. Regardless, if
graphics-exposures in gc is True, GraphicsExposure events for the
corresponding destination regions are generated.
If graphics-exposures is True but no regions are exposed, then a
NoExposure event is generated.
GC components: alu-function, plane-mask, subwindow-mode,
graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
CopyPlane
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
bit-plane: CARD32
Errors: Drawable, GContext, Value, Match
Src-drawable must have the same root as dst-drawable (else a Match
error), but need not have the same depth. Bit-plane must have exactly
one bit set. Effectively, that plane of the src-drawable and the
foreground/background pixels in gc are combined to form a pixmap of the
same depth as dst-drawable, and the equivalent of a CopyArea is
performed, with all the same exposure semantics.
GC components: alu-function, plane-mask, foreground, background,
subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,
clip-mask
PolyPoint
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Combines the foreground pixel in gc with the pixel at each point in the
drawable. The points are drawn in the order listed.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, foreground, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
PolyLine
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Draws lines between each pair of points (point[i], point[i+1]). The
lines are drawn in the order listed. The lines join correctly at all
intermediate points, and if the first and last points coincide, the
first and last lines also join correctly.
For any given line, no pixel is drawn more than once. If thin (zero
line-width) lines intersect, the intersecting pixels are drawn multiple
times. If wide lines intersect, the intersecting pixels are drawn only
once, as though the entire PolyLine were a single filled shape.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolySegment
drawable: DRAWABLE
gc: GCONTEXT
segments: LISTofSEGMENT
where SEGMENT: [x1, y1, x2, y2: INT16]
Errors: Drawable, GContext, Match
For each segment, draws a line between [x1, y1] and [x2, y2]. The
lines are drawn in the order listed. No joining is performed at
coincident end points. For any given line, no pixel is drawn more than
once. If lines intersect, the intersecting pixels are drawn multiple
times.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolyRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Draws the outlines of the specified rectangles, as if a five-point
PolyLine were specified for each rectangle. The x and y coordinates of
each rectangle are relative to the drawable's origin, and define the
upper left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, line-width, line-style,
join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 2 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082720.7.RWS@KILLINGTON.LCS.MIT.EDU>
SECTION 6. KEYBOARDS
Keycodes are always in the inclusive range [8,255].
For keyboards with both left-side and right-side modifier keys (e.g., Shift
and Control), the mask bits in the protocol always define the OR of the keys.
If electronically distinguishable, they can have separate up/down events
generated, and clients that want to distinguish can track the individual
states manually.
<As part of the core we need to define a universal association between keycaps
and keycodes. A keycap is the graphical information imprinted on a keyboard
key, e.g., "$ 4", "T", "+ =".>
SECTION 7. POINTERS
Buttons are always numbered starting with one.
SECTION 8. PREDEFINED ATOMS
Predefined atoms are not strictly necessary, and may not be useful in all
environments, but will eliminate many InternAtom requests in most
applications. The core protocol imposes no semantics on these names, except
as they are used in FONTPROP structures (see QueryFont). Note that
upper/lower case matters.
BITMAP ICON_SIZE RGB_GREEN_MAP
COMMAND ITALIC_ANGLE RGB_RED_MAP
COPYRIGHT MAX_SPACE SECONDARY
CUT_BUFFER0 MIN_SPACE SIZE_HINTS
CUT_BUFFER1 NAME STRIKEOUT_ASCENT
CUT_BUFFER2 NORMAL_HINTS STRIKEOUT_DESCENT
CUT_BUFFER3 NORM_SPACE STRING
CUT_BUFFER4 PIXMAP SUBSCRIPT_X
CUT_BUFFER5 POINT_SIZE SUBSCRIPT_Y
CUT_BUFFER6 PRIMARY SUPERSCRIPT_X
CUT_BUFFER7 QUAD_WIDTH SUPERSCRIPT_Y
DEFAULT_CHAR RECTANGLE UNDERLINE_POSITION
END_SPACE RESIZE_HINT UNDERLINE_THICKNESS
FACE_NAME RESOLUTION WEIGHT
FAMILY_NAME RGB_BEST_MAP WINDOW
FONT_ASCENT RGB_BLUE_MAP WM_HINTS
FONT_DESCENT RGB_COLOR_MAP X_HEIGHT
ICON RGB_DEFAULT_MAP ZOOM_HINTS
ICON_NAME
SECTION 9. CONNECTION SETUP
For remote clients, the X protocol can be built on top of any reliable byte
stream. For TCP connections, displays on a given host a numbered starting
from 0, and the server for display N listens and accepts connections on port
6000+N.
The client must send an initial byte of data to identify the byte order to be
employed. The value of the byte must be octal 102 or 154. The value 102
(ASCII uppercase B) means values are transmitted most significant byte first,
and value 154 (ASCII lowercase l) means values are transmitted least
significant byte first. Except where explicitly noted in the protocol, all
16-bit and 32-bit quantities sent by the client must be transmitted with this
byte order, and all 16-bit and 32-bit quantities returned by the server will
be transmitted with this byte order.
Following the byte-order byte, the following information is sent by the client
at connection setup:
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
The version numbers indicate what version of the protocol the client
expects the server to implement. See below for an explanation.
The authorization name indicates what authorization protocol the client
expects the server to use, and the data is specific to that protocol.
Specification of valid authorization mechanisms is not part of the core
X protocol. It is hoped that eventually one authorization protocol
will be agreed upon. In the mean time, a server that implements a
different protocol than the client expects, or a server that only
implements the host-based mechanism, will simply ignore this
information.
Received by the client at connection setup:
success: BOOL
protocol-major-version: CARD16
protocol-minor-version: CARD16
length: CARD16
Length is the amount of additional data to follow, in units of 4 bytes.
The version numbers are an escape hatch in case future revisions of the
protocol are necessary. In general, the major version would increment
for incompatible changes, and the minor version would increment for
small upward compatible changes. Barring changes, the major version
will be eleven, and the minor version will be zero. The protocol
version numbers returned indicate the protocol the server actually
supports. This might not equal the version sent by the client. The
server can (but need not) refuse connections from clients that offer a
different version than the server supports. A server can (but need
not) support more than one version simultaneously.
Additional data received if authorization fails:
reason: STRING8
Additional data received if authorization is accepted:
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order: {LSBFirst, MSBFirst}
bitmap-format-scanline-unit: {8, 16, 32}
bitmap-format-scanline-pad: {8, 16, 32}
bitmap-format-bit-order: {LeastSignificant, MostSignificant}
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
keyboard: DEVICE
pointer: DEVICE
motion-buffer-size: CARD32
maximum-request-length: CARD16
where
FORMAT: [depth: CARD8,
bits-per-pixel: {4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN: [root: WINDOW
device: DEVICE
width-in-pixels, height-in-pixels: CARD16
width-in-millimeters, height-in-millimeters: CARD16
allowed-depths: LISTofDEPTH
root-depth: CARD8
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
min-installed-maps, max-installed-maps: CARD16
backing-stores: {Never, WhenMapped, Always}
save-unders: BOOL
current-input-masks: SETofEVENT]
DEPTH: [depth: CARD8
visuals: LISTofVISUALTYPE]
VISUALTYPE: [visual-id: VISUALID
class: {StaticGray, StaticColor, TrueColor,
GrayScale, PseudoColor, DirectColor}
red-mask, green-mask, blue-mask: CARD32
bits-per-rgb-value: CARD8
colormap-entries: CARD16]
Per server information:
The vendor string gives some indentification of the owner of the server
implementation. The semantics of the release-number is controlled by
the vendor.
The resource-id-mask contains a single contiguous set of bits (at least
18); the client allocates resource ids by choosing a value with (only)
some subset of these bits set, and ORing it with resource-id-base.
Only values constructed in this way can be used to name newly created
resources over this connection. Resource ids never have the top 3 bits
set. The client is not restricted to linear or contiguous allocation
of resource ids. Once an id has been freed, it can be reused, but this
should not be necessary. An id must be unique with respect to the ids
of all other resources, not just other resources of the same type.
Although the server is in general responsible for byte swapping data to
match the client, images are always transmitted and received in formats
(including byte order) specified by the server. The byte order for
images is given by image-byte-order, and applies to each scanline unit
in XYFormat (bitmap) format, and to each pixel value in ZFormat.
A bitmap is represented in scanline order. Each scanline is padded to
a multiple of bits as given by bitmap-format-scanline-pad. The pad
bits are of arbitrary value. The scanline is quantized in multiples of
bits as given by bitmap-format-scanline-unit. Within each unit, the
leftmost bit in the bitmap is either the least or most significant bit
in the unit, as given by bitmap-format-bit-order. If a pixmap is
represented in XYFormat, each plane is represented as a bitmap, and the
planes appear from most to least significant in bit order.
For each pixmap depth supported by some screen, pixmap-formats lists
the ZFormat used to represent images of that depth. In ZFormat, the
pixels are in scanline order, left to right within a scanline. The
number of bits used to hold each pixel is given by bits-per-pixel, and
may be larger than strictly required by the depth. When the
bits-per-pixel is 4, the order of nibbles in the byte is the same as
the image byte-order. Each scanline is padded to a multiple of bits as
given by scanline-pad.
How a pointing device roams the screens is up to the server
implementation, and is transparent to the protocol. No geometry among
screens is defined.
The server may retain the recent history of pointer motion, and to a
finer granularity than is reported by MotionNotify events. Such
history is available via the GetPointerMotions request. The
approximate size of the history buffer is given by motion-buffer-size.
Maximum-request-length specifies the maximum length of a request, in
4-byte units, accepted by the server; i.e., this is the maximum value
that can appear in the length field of a request. Requests larger than
this generate a Length error, and the server will read and simply
discard the entire request. Maximum-request-length will always be at
least 4096 (i.e., requests of length up to and including 16384 bytes
will be accepted by all servers).
Per screen information:
The allowed-depths specifies what pixmap and window depths are
supported. Pixmaps are supported for each depth listed, and windows of
that depth are supported if at least one visual type is listed for the
depth. A pixmap depth of one is always supported and listed, but
windows of depth one might not be supported. A depth of zero is never
listed, but zero-depth InputOnly windows are always supported.
Root-depth and root-visual specify the depth and visual type of the
root window. Width-in-pixels and height-in-pixels specify the size of
the root window (which cannot be changed). The class of the root
window is always InputOutput. Width-in-millimeters and
height-in-millimeters can be used to determine the physical size and
the aspect ratio.
The default-colormap is the one initially associated with the root
window. Clients with minimal color requirements creating windows of
the same depth as the root may want to allocate from this map by
default.
Black-pixel and white-pixel can be used in implementing a "monochrome"
application. These pixel values are for permanently allocated entries
in the default-colormap; the actual RGB values may be settable on some
screens.
The border of the root window is initially a pixmap filled with the
black-pixel. The initial background of the root window is a pixmap
filled with some unspecified two-color pattern using black-pixel and
white-pixel.
Min-installed-maps specifies the number of maps that can be guaranteed
to installed simultaneously (with InstallColormap), regardless of the
number of entries allocated in each map. Max-installed-maps specifies
the maximum number of maps that might possibly be installed
simultaneously, depending on their allocations. For the typical case
of a single hardware colormap, both values will be one.
Backing-stores indicates when the server supports backing stores for
this screen, although it may be storage limited in the number of
windows it can support at once. If save-unders is True, then the
server can support the save-under mode in CreateWindow and
ChangeWindowAttributes, although again it may be storage limited.
The current-input-events is what GetWindowAttributes would return for
the all-event-masks for the root window.
Per visual-type information:
A given visual type might be listed for more than one depth, or for
more than one screen.
For PseudoColor, a pixel value indexes a colormap to produce
independent RGB values; the RGB values can be changed dynamically.
GrayScale is treated the same as PseudoColor, except which primary
drives the screen is undefined, so the client should always store the
same value for red, green, and blue in colormaps. For DirectColor, a
pixel value is decomposed into separate RGB subfields, and each
subfield separately indexes the colormap for the corresponding value;
The RGB values can be changed dynamically. TrueColor is treated the
same as DirectColor, except the colormap has predefined read-only RGB
values, which are server-dependent, but provide (near-)linear ramps in
each primary. StaticColor is treated the same as PseudoColor, except
the colormap has predefined read-only RGB values, which are
server-dependent. StaticGray is treated the same as StaticColor,
except the red, green, and blue values are equal for any single pixel
value, resulting in shades of gray. StaticGray with a two-entry
colormap can be thought of as "monochrome".
The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor; each has one contiguous set of bits, with no
intersections.
The bits-per-rgb-value specifies the log base 2 of the approximate
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are always passed in the protocol within a 16-bit
spectrum.
The colormap-entries defines the number of available colormap entries
in a newly created colormap. For DirectColor and TrueColor, this will
usually be the size of an individual pixel subfield.
SECTION 10. REQUESTS
CreateWindow
wid, parent: WINDOW
class: {InputOutput, InputOnly, CopyFromParent}
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Window, Pixmap, Colormap, Cursor, Match, Value, Alloc
Creates an unmapped window, and assigns the identifier wid to it.
A class of CopyFromParent means the class is taken from the parent. A
depth of zero for class InputOutput or CopyFromParent means the depth
is taken from the parent. A visual of CopyFromParent means the visual
type is taken from the parent. For class InputOutput, the visual type
and depth must be a combination supported for the screen (else a Match
error); the depth need not be the same as the parent, but the parent
must not be of class InputOnly (else a Match error). For class
InputOnly, the depth must be zero (else a Match error), and the visual
must be one supported for the screen (else a Match error), but the
parent may have any depth and class.
The server essentially acts as if InputOnly windows do not exist for
the purposes of graphics requests, exposure processing, and
VisibilityNotify events. An InputOnly window cannot be used as a
drawable (as a source or destination for graphics requests). InputOnly
and InputOutput windows act identically in other respects (properties,
grabs, input control, and so on).
The window is placed on top in the stacking order with respect to
siblings. The x and y coordinates are relative to the parent's origin,
and specify the position of the upper left outer corner of the window
(not the origin). The width and height specify the inside size, not
including the border, and must be non-zero. The border-width for an
InputOnly window must be zero (else a Match error).
The value-mask and value-list specify attributes of the window that are
to be explicitly initialized. The possible values are:
background-pixmap: PIXMAP or None or ParentRelative
background-pixel: CARD32
border-pixmap: PIXMAP or CopyFromParent
border-pixel: CARD32
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
colormap: COLORMAP or CopyFromParent
cursor: CURSOR or None
The default values, when attributes are not explicitly initialized,
are:
background-pixmap: None
border-pixmap: CopyFromParent
bit-gravity: Forget
win-gravity: NorthWest
backing-store: NotUseful
backing-bit-planes: all ones
backing-pixel: zero
save-under: False
event-mask: {} (empty set)
do-not-propagate-mask: {} (empty set)
override-redirect: False
colormap: CopyFromParent
cursor: None
Only the following attributes are defined for InputOnly windows:
win-gravity, event-mask, do-not-propagate-mask, and cursor. It is a
Match error to specify any other attributes for InputOnly windows.
If background-pixmap is given, it overrides the default
background-pixel. The background pixmap and the window must have the
same root and the same depth (else a Match error). Any size pixmap can
be used, although some sizes may be faster than others. If background
None is specifed, the window has no defined background. If background
ParentRelative is specified, the parent's background is used, but the
window must have the same depth as the parent (else a Match error); if
the parent has background None, then the window will also have
background None. A copy of the parent's background is not made; the
parent's background is reexamined each time the window background is
required. If background-pixel is given, it overrides the default and
any background-pixmap given, and a pixmap of undefined size filled with
background-pixel is used for the background. For a ParentRelative
background, the background tile origin always aligns with the parent's
background tile origin; otherwise the background tile origin is always
the window origin.
When regions of the window are exposed and the server has not retained
the contents, the server automatically tiles the regions with the
window's background unless the window has a background of None, in
which case the previous screen contents are simply left in place.
Exposure events are then generated for the regions, even if the
background is None.
The border tile origin is always the same as the background tile
origin. If border-pixmap is given, it overrides the default
border-pixel. The border pixmap and the window must have the same root
and the same depth (else a Match error). Any size pixmap can be used,
although some sizes may faster than others. If CopyFromParent is
given, the parent's border pixmap is copied (subsequent changes to the
parent do not affect the child), but the window must have the same
depth as the parent (else a Match error). If border-pixel is given, it
overrides the default and any border-pixmap given, and a pixmap of
undefined size filled with border-pixel is used for the border.
Output to a window is always clipped to the inside of the window, so
that the border is never affected.
The bit-gravity defines which region of the window should be retained
if the window is resized, and win-gravity defines how the window should
be repositioned if the parent is resized; see ConfigureWindow.
A backing-store of WhenMapped advises the server that maintaining
contents of obscured regions when the window is mapped would be
beneficial. A backing-store of Always advises the server that
maintaining contents even when the window is unmapped would be
beneficial. Note that, even if the window is larger than its parent,
the server should maintain complete contents, not just the region
within the parent boundaries. If the server maintains contents,
Exposure events will not be generated, but the server may stop
maintaining contents at any time. A value of NotUseful advises the
server that maintaining contents is unnecessary, although a server may
still choose to maintain contents.
Backing-bit-planes indicates (with one bits) which bit planes of the
window hold dynamic data that must be preserved in backing-stores.
Backing-pixel specifies what value to use in planes not covered by
backing-bit-planes. The server is free to only save the specified bit
planes in the backing-store, and regenerate the remaining planes with
the specified pixel value.
If save-under is True, the server is advised that, when this window is
mapped, saving the contents of windows it obscures would be beneficial.
The event-mask defines which events the client is interested in for
this window (or, for some event types, inferiors of the window). The
do-not-propagate-mask defines which events should not be propagated to
ancestor windows when no client has the event type selected in this
window.
Override-redirect specifies whether map and configure requests on this
window should override a SubstructureRedirect on the parent, typically
to inform a window manager not to tamper with the window.
The colormap specifies the colormap, that best reflects the "true"
colors of the window. Servers capable of supporting multiple hardware
colormaps may use this information, and window managers may use it for
InstallColormap requests. The colormap must have the same visual type
as the window (else a Match error). If CopyFromParent is specified,
the parent's colormap is copied (subsequent changes to the parent do
not affect the child), but the window must have the same visual type as
the parent (else a Match error) and the parent must not have a colormap
of None (else a Match error).
If a cursor is specified, it will be used whenever the pointer is in
the window. If None is specified, the parent's cursor will be used
when the pointer is in the window, and any change in the parent's
cursor will cause an immediate change in the displayed cursor.
This request generates a CreateNotify event.
The background and border pixmaps and the cursor may be freed
immediately if no further explicit references to them are to be made.
Subsequent drawing into the background or border pixmap has an
undefined effect on the window state; the server might or might not
make a copy of the pixmap.
ChangeWindowAttributes
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Pixmap, Colormap, Cursor, Match, Value, Access
The value-mask and value-list specify which attributes are to be
changed. The values and restrictions are the same as for CreateWindow.
Changing the background does not cause the window contents to be
changed. Setting the border, or changing the background such that the
border tile origin changes, causes the border to be repainted.
Changing the background of a root window to None or ParentRelative
restores the default background pixmap. Changing the border of a root
window to CopyFromParent restores the default border pixmap.
Changing the win-gravity does not affect the current position of the
window.
Changing the backing-store of an obscured window to WhenMapped or
Always, or changing the backing-bit-planes, backing-pixel, or
save-under of a mapped window, may have no immediate effect.
Multiple clients can select input on the same window; their event-masks
are disjoint. When an event is generated it will be reported to all
interested clients. However, at most one client at a time can select
for SubstructureRedirect, at most one client at a time can select for
ResizeRedirect, and at most one client at a time can select for
ButtonPress.
There is only one do-not-propagate-mask for a window, not one per
client.
Changing the colormap of a window (i.e., defining a new map, not
changing the contents of the existing map) generates a ColormapNotify
event. Changing the colormap of a visible window may have no immediate
effect on the screen; see InstallColormap.
Changing the cursor of a root window to None restores the default
cursor.
The order in which attributes are verified and altered is server
dependent. If an error is generated, a subset of the attributes may
have been altered.
GetWindowAttributes
window: WINDOW
=>
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable, Viewable}
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
Errors: Window
Returns current attributes of the window. All-event-masks is the
inclusive-OR of all event masks selected on the window by clients.
Your-event-mask is the event mask selected by the querying client.
DestroyWindow
window: WINDOW
Errors: Window
If the argument window is mapped, an UnmapWindow request is performed
automatically. The window and all inferiors are then destroyed, and a
DestroyNotify event is generated for each window, in order from the
argument window downwards, with unspecified order among siblings at
each level.
Normal exposure processing on formerly obscured windows is performed.
If the window is a root window, this request has no effect.
DestroySubwindows
window: WINDOW
Errors: Window
Performs a DestroyWindow on all children of the window, in bottom to
top stacking order.
ChangeSaveSet
window: WINDOW
mode: {Insert, Delete}
Errors: Window, Match, Value
Adds or removes the specified window from the client's "save-set". The
window must have been created by some other client (else a Match
error). The use of the save-set is described in Section 11.
Windows are removed automatically from the save-set by the server when
they are destroyed.
ReparentWindow
window, parent: WINDOW
x, y: INT16
Errors: Window, Match
If the window is mapped, an UnmapWindow request is performed
automatically first. The window is then removed from its current
position in the hierarchy, and is inserted as a child of the specified
parent. The x and y coordinates are relative to the parent's origin,
and specify the new position of the upper left outer corner of the
window. The window is placed on top in the stacking order with respect
to siblings. A ReparentNotify event is then generated. The
override-redirect attribute of the window is passed on in this event; a
value of True indicates that a window manager should not tamper with
this window. Finally, if the window was originally mapped, a MapWindow
request is performed automatically.
Normal exposure processing on formerly obscured windows is performed.
The server might not generate exposure events for regions from the
initial unmap that are immediately obscured by the final map.
A Match error is generated if the new parent is not on the same screen
as the old parent, or if the new parent is the window itself or an
inferior of the window, or if the window has a ParentRelative
background and the new parent is not the same depth as the window.
MapWindow
window: WINDOW
Errors: Window
If the window is already mapped, this request has no effect.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
MapRequest event is generated, but the window remains unmapped.
Otherwise, the window is mapped and a MapNotify event is generated.
If the window is now viewable and its contents had been discarded, then
the window is tiled with its background (if no background is defined,
the existing screen contents are not altered) and one or more exposure
events are generated. If a backing-store has been maintained while the
window was unmapped, no exposure events are generated. If a
backing-store will now be maintained, a full-window exposure is always
generated; otherwise only visible regions may be reported. Similar
tiling and exposure take place for any newly viewable inferiors.
MapSubwindows
window: WINDOW
Errors: Window
Performs a MapWindow request on all unmapped children of the window, in
top to bottom stacking order.
UnmapWindow
window: WINDOW
Errors: Window
If the window is already unmapped, this request has no effect.
Otherwise, the window is unmapped and an UnmapNotify event is
generated. Normal exposure processing on formerly obscured windows is
performed.
UnmapSubwindows
window: WINDOW
Errors: Window
Performs an UnmapWindow request on all mapped children of the window,
in bottom to top stacking order.
ConfigureWindow
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match, Value
Changes the configuration of the window. The value-mask and value-list
specify which values are to be given. The possible values are:
x: INT16
y: INT16
width: CARD16
height: CARD16
border-width: CARD16
sibling: WINDOW
stack-mode: {Above, Below, TopIf, BottomIf, Opposite}
The x and y coordinates are relative to the parent's origin, and
specify the position of the upper left outer corner of the window. The
width and height specify the inside size, not including the border, and
must be non-zero. It is a Match error to attempt to make the
border-width of an InputOnly window non-zero.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
ConfigureRequest event is generated, and no further processing is
performed. Otherwise, the following is performed.
If some other client has selected ResizeRedirect on the window and the
width or height of the window is being changed, then a ResizeRequest
event is generated, and the current width and height are used instead
in the following.
The geometry of the window is changed as specified and the window is
restacked among siblings as described below, and a ConfigureNotify
event is generated. If the width or height of the window has actually
changed, then children of the window are affected as described below.
Exposure processing is performed on formerly obscured windows.
Changing the width or height of the window causes its contents to be
moved or lost, depending on the bit-gravity of the window, and causes
children to be reconfigured, depending on their win-gravity. For a
change of width and height of W and H, we define the [x, y] pairs:
NorthWest: [0, 0]
North: [W/2, 0]
NorthEast: [W, 0]
West: [0, H/2]
Center: [W/2, H/2]
East: [W, H/2]
SouthWest: [0, H]
South: [W/2, H]
SouthEast: [W, H]
When a window with one of these bit-gravities is resized, the
corresponding pair defines the change in position of each pixel in the
window. When a window with one of these win-gravities has its parent
window resized, the corresponding pair defines the change in position
of the window within the parent. When a window is so repositioned, a
GravityNotify event is generated.
A gravity of Static indicates that the contents or origin should not
move relative to the origin of the root window. If the change in size
of the window is coupled with a change in position of [X, Y], then for
bit-gravity the change in position of each pixel is [-X, -Y], and for
win-gravity the change in position of a child when its parent is so
resized is [-X, -Y]. Note that Static gravity still only takes effect
when the width or height of the window is changed, not when the window
is simply moved.
A bit-gravity of Forget indicates that the window contents are always
discarded after a size change; the window is tiled with its background
(if no background is defined, the existing screen contents are not
altered) and one or more exposure events are generated. A server may
also ignore the specified bit-gravity and use Forget instead.
A win-gravity of Unmap is like NorthWest, but the child is also
unmapped when the parent is resized, and an UnmapNotify event is
generated.
If a sibling and a stack-mode is specified, the window is restacked as
follows:
Above: window is placed just above sibling
Below: window is placed just below sibling
TopIf: if sibling occludes window, then window is placed
at the top of the stack
BottomIf: if window occludes sibling, then window is
placed at the bottom of the stack
Opposite: if sibling occludes window, then window is placed at the
top of the stack, else if window occludes sibling, then
window is placed at the bottom of the stack
If a stack-mode is specified but no sibling is specified, the window is
restacked as follows:
Above: window is placed at the top of the stack
Below: window is placed at the bottom of the stack
TopIf: if any sibling occludes window, then window is placed at
the top of the stack
BottomIf: if window occludes any sibling, then window is placed at
the bottom of the stack
Opposite: if any sibling occludes window, then window is placed at
the top of the stack, else if window occludes any
sibling, then window is placed at the bottom of the stack
It is a Match error if a sibling is specified without a stack-mode, or
if the window is not actually a sibling.
Note that the computations for BottomIf, TopIf, and Opposite are
performed with respect to the window's final geometry (as controlled by
the other arguments to the request), not its initial geometry.
CirculateWindow
window: WINDOW
direction: {RaiseLowest, LowerHighest}
Errors: Window, Value
If some other client has selected SubstructureRedirect on the window,
then a CirculateRequest event is generated, and no further processing
is performed. Otherwise, the following is performed, and then a
CirculateNotify event is generated if the window is actually restacked.
For RaiseLowest, raises the lowest mapped child (if any) that is
occluded by another child to the top of the stack. For LowerHighest,
lowers the highest mapped child (if any) that occludes another child to
the bottom of the stack. Exposure processing is performed on formerly
obscured windows.
∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:31:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 6 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082914.1.RWS@KILLINGTON.LCS.MIT.EDU>
SetPointerMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the pointer. Elements of the list are indexed
starting from one. The length of the list must be the same as
GetPointerMapping would return. The index is a "core" button number,
and the element of the list defines the "effective" number.
A zero element disables a button, and elements are not restricted in
value by the number of physical buttons, but no two elements can have
the same non-zero value.
If any of the buttons to be altered are currently in the down state,
the status reply is Busy and the mapping is not changed.
GetPointerMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the pointer. Elements of the list are
indexed starting from one. The length of the list indicates the number
of physical buttons.
The nominal mapping for a pointer is the identity mapping; map[i]=i.
ChangePointerControl
do-acceleration, do-threshold: BOOL
acceleration-numerator, acceleration-denominator: INT16
threshold: INT16
Errors: Match, Value
Defines how the pointer moves. The acceleration is a multiplier for
movement, expressed as a fraction. For example, specifying 3/1 means
the pointer moves three times as fast as normal. The fraction may be
rounded arbitrarily by the server. Acceleration only takes effect if
the pointer moves more than threshold pixels at once, and only applies
to the amount beyond the threshold. Setting a value to -1 restores the
default. Other negative values generate a Value error, as does a zero
value for acceleration-denominator.
GetPointerControl
=>
acceleration-numerator, acceleration-denominator: CARD16
threshold: CARD16
Errors: Match
Returns the current acceleration and threshold for the pointer.
SetScreenSaver
timeout, interval: INT16
prefer-blanking: {Yes, No, Default}
allow-exposures: {Yes, No, Default}
Errors: Value
Timeout and interval are specified in minutes; setting a value to -1
restores the default. Other negative values generate a Value error.
If the timeout value is zero, screen-saver is disabled. If the timeout
value is non-zero, screen-saver is enabled. Once screen-saver is
enabled, if no input from the keyboard or pointer is generated for
timeout minutes, screen-saver is activated. For each screen, if
blanking is preferred and the hardware supports video blanking, the
screen will simply go blank. Otherwise, if either exposures are
allowed or the screen can be regenerated without sending exposure
events to clients, the screen is tiled with the root window background
tile, randomly re-origined each interval minutes if the interval value
is non-zero. Otherwise, the state of the screen does not change and
screen-saver is not activated. Screen-saver is deactivated, and all
screen states are restored, at the next keyboard or pointer input or at
the next ForceScreenSaver with mode Reset.
GetScreenSaver
=>
timeout, interval: CARD16
prefer-blanking: {Yes, No}
allow-exposures: {Yes, No}
Returns the current screen-saver control values.
ForceScreenSaver
mode: {Activate, Reset}
If the mode is Activate and screen-saver is currently deactivated, then
screen-saver is activated (even if screen-saver has been disabled with
a timeout value of zero). If the mode is Reset and screen-saver is
currently enabled, then screen-saver is deactivated (if it was
activated), and then the activation timer is reset to its initial
state, as if device input had just been received.
ChangeHosts
mode: {Insert, Delete}
host: HOST
Errors: Access, Value
Adds or removes the specified host from the access control list. When
the access control mechanism is enabled and a host attempts to
establish a connection to the server, the host must be in this list or
the server will refuse the connection.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
An initial access control list can be specified, typically by naming a
file that the server reads at startup and reset.
ListHosts
=>
mode: {Enabled, Disabled}
hosts: LISTofHOST
Returns the hosts on the access control list, and whether use of the
list at connection setup is currently enabled or disabled.
Each HOST is padded to a multiple of four bytes.
ChangeAccessControl
mode: {Enable, Disable}
Errors: Value, Access
Enables or disables the use of the access control list at connection
setups.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
ChangeCloseDownMode
mode: {Destroy, RetainPermanent, RetainTemporary}
Errors: Value
Defines what will happen to the client's resources at connection close.
A connection starts in Destroy mode. The meaning of the close-down
mode is described in Section 11.
KillClient
resource: CARD32 or AllTemporary
Errors: Value
If a valid resource is specified, forces a close-down of the client
that created the resource. If the client has already terminated in
either RetainPermanent or RetainTemporary mode, all of the client's
resources are destroyed (see Section 11). If AllTemporary is
specified, then the resources of all clients that have terminated in
RetainTemporary are destroyed.
NoOperation
This request has no arguments and no results, but the request length
field can be non-zero, allowing the request to be any multiple of 4
bytes in length. The bytes contained in the request are uninterpreted
by the server.
This request can be used in its minimum 4 byte form as "padding" where
necessary by client libraries that find it convenient to force requests
to begin on 64-bit boundaries.
SECTION 11. CONNECTION CLOSE
What happens at connection close:
All event selections made by the client are discarded. If the client
has the pointer actively grabbed, an UngrabPointer is performed. If
the client has the keyboard actively grabbed, an UngrabKeyboard is
performed. All passive grabs by the client are released. If the
client has the server grabbed, and UngrabServer is performed. If
close-down mode (see ChangeCloseDownMode) is RetainPermanent or
RetainTemporary, then all resources (including colormap entries)
allocated by the client are marked as "permanent" or "temporary",
respectively (but this does not prevent other clients from explicitly
destroying them). If the mode is Destroy, then all of the client's
resources are destroyed as described below.
What happens when a client's resources are destroyed:
For each window in the client's save-set, if the window is an inferior
of a window created by the client, the save-set window is reparented to
the closest ancestor such that the save-set window is not an inferior
of a window created by the client. If the save-set window is unmapped,
a MapWindow request is performed on it. After save-set processing, all
windows created by the client are destroyed. For each non-window
resource created by the client, the appropriate Free request is
performed. All colors and colormap entries allocated by the client are
freed.
What happens when the last connection to a server closes:
A server goes through a cycle, of having no connections and having some
connections. At every transition to the state of having no
connections, the server "resets" its state, as if it had just been
started. This starts by destroying all lingering resources from
clients that have terminated in RetainPermanent or RetainTemporary
mode. It additionally includes deleting all but the predefined atom
identifiers, deleting all properties on all root windows, resetting all
device maps and attributes (key click, bell volume, acceleration),
resetting the access control list, restoring the standard root tiles
and cursors, restoring the default font path, and restoring the input
focus to state PointerRoot.
SECTION 12. EVENTS
When a button is pressed with the pointer in some window W, and no active
pointer grab is in progress, then the ancestors of W are searched from the
root down, looking for a passive grab to activate. If no matching passive
grab on the button exists, then an active grab is started automatically for
the client receiving the event, and the last-pointer-grab time is set to the
current server time. The effect is essentially equivalent to a GrabButton
with arguments:
event-window: the event window
event-mask: the client's selected events on the event window
pointer-mode and keyboard-mode: Asynchronous
owner-events: True if the client has OwnerGrabButton selected on the
event window, else False
confine-to: None
cursor: None
The grab is terminated automatically when all buttons are released.
UngrabPointer and ChangeActiveGrab can both be used to modify the active grab.
KeyPress
and
KeyRelease
and
ButtonPress
and
ButtonRelease
and
MotionNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
detail: <see below>
state: SETofKEYBUTMASK
time: TIMESTAMP
Generated when a key or button changes state, or the pointer moves.
The "source" of the event is the window the pointer is in. The window
with respect to which the event is normally reported is found by
looking up the hierarchy (starting with the source window) for the
first window on which any client has selected interest in the event,
provided no intervening window prohibits event generation by including
the event type in its do-not-propagate-mask. The actual window used
for reporting can be modified by active grabs and the focus window.
The window the event is reported with respect to is called the "event"
window.
Root is the root window of the "source" window, and root-x and root-y
are the pointer coordinates relative to root's origin at the time of
the event. Event is the "event" window. If the event window is on the
same screen as root, then event-x and event-y are the pointer
coordinates relative to the event window's origin; otherwise event-x
and event-y are zero. If the source window is an inferior of the event
window, then child is set to the child of the event window that is an
ancestor of the source window. The state component gives the state of
the buttons and modifier keys just before the event. The detail
component varies with the event type:
KeyPress, KeyRelease: KEYCODE
ButtonPress, ButtonRelease: BUTTON
MotionNotify: {Normal, Hint}
MotionNotify events are only generated when the motion begins and ends
in the window. The granularity of motion events is not guaranteed, but
a client selecting for motion events is guaranteed to get at least one
event when the pointer moves and comes to rest. Selecting
PointerMotion receives events independent of the state of the pointer
buttons. By selecting some subset of Button[1-5]Motion instead,
MotionNotify events will only be received when one or more of the
specified buttons are pressed. By selecting ButtonMotion, MotionNotify
events will received only when at least one button is pressed. The
events are always of type MotionNotify, independent of the selection.
If PointerMotionHint is selected, the server is free to send only one
MotionNotify event (with detail Hint) to the client for the event
window, until either the key or button state changes, or the pointer
leaves the event window, or the client issues a QueryPointer or
GetMotionEvents request.
EnterNotify
and
LeaveNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
mode: {Normal, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual}
focus: BOOL
state: SETofKEYBUTMASK
time: TIMESTAMP
If pointer motion causes the pointer to be in a different window than
before, EnterNotify and LeaveNotify events are generated instead of a
MotionNotify event. Only clients selecting EnterWindow on a window
receive EnterNotify events, and only clients selection LeaveNotify
receive LeaveNotify events. The pointer position reported in the event
is always the "final" position, not the "initial" position of the
pointer. In a LeaveNotify event, if a child of the event window
contains the "initial" position of the pointer, then the child
component is set to that child, otherwise it is None. For an
EnterNotify event, if a child of the event window contains the "final"
pointer position, then the child component is set to that child,
otherwise it is None. If the the event window is the focus window or
an inferior of the focus window, then focus is True, and otherwise
focus is False.
Normal pointer motion events have mode Normal; pseudo-motion events
when a grab actives have mode Grab, and pseudo-motion events when a
grab deactivates have mode Ungrab.
Normal events are generated as follows:
When the pointer moves from window A to window B, and A is an inferior
of B:
LeaveNotify with detail Ancestor is generated on A
LeaveNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Inferior is generated on B
When the pointer moves from window A to window B, and B is an inferior
of A:
LeaveNotify with detail Inferior is generated on A
EnterNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Ancestor is generated on B
When the pointer moves from window A to window B, with window C being
their least common ancestor:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
EnterNotify with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
EnterNotify with detail Nonlinear is generated on B
When the pointer moves from window A to window B, on different screens:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
EnterNotify with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
EnterNotify with detail Nonlinear is generated on B
When a pointer grab activates (but after any initial warp into a confine-to
window), with G the grab-window for the grab and P the window the pointer
is in:
EnterNotify and LeaveNotify events with mode Grab are generated (as for
Normal above) as if the pointer were to suddenly warp from its current
position in P to some position in G. However, the pointer does not
warp, and the pointer position is used as both the "initial" and
"final" positions for the events.
When a pointer grab deactivates, with G the grab-window for the grab and P
the window the pointer is in:
EnterNotify and LeaveNotify events with mode Ungrab are generated (as
for Normal above) as if the pointer were to suddenly warp from from
some position in G to its current position in P. However, the pointer
does not warp, and the current pointer position is used as both the
"initial" and "final" positions for the events.
FocusIn
and
FocusOut
event: WINDOW
mode: {Normal, WhileGrabbed, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual,
Pointer, PointerRoot, None}
Generated when the input focus changes. Reported to clients selecting
FocusChange on the window. Events generated by SetInputFocus when the
keyboard is not grabbed have mode Normal; events generated by
SetInputFocus when the keyboard is grabbed have mode WhileGrabbed;
events generated when a keyboard grab actives have mode Grab, and
events generated when a keyboard grab deactivates have mode Ungrab.
Normal and WhileGrabbed events are generated as follows:
When the focus moves from window A to window B, and A is an inferior of B,
with the pointer in window P:
FocusOut with detail Ancestor is generated on A
FocusOut with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Inferior is generated on B
If P is an inferior of B, but P is not A or an inferior of A or an
ancestor of A, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, and B is an inferior of A,
with the pointer in window P:
If P is an inferior of A, but P is not A or an inferior of B or an
ancestor of B, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Inferior is generated on A
FocusIn with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Ancestor is generated on B
When the focus moves from window A to window B, with window C being their
least common ancestor, and with the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
FocusIn with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, on different screens, with
the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to PointerRoot (or None)
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail PointerRoot (or None) is generated on all root
windows
When the focus moves from PointerRoot (or None) to window A:
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail NonlinearVirtual is generated on each window from
A's root down to but not including A (in order)
FocusIn with detail Nonlinear is generated on A
If P is an inferior of A, FocusIn with detail Pointer is generated on
each window below A down to and including P (in order)
When the focus moves from PointerRoot to None (or vice versa):
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail None (or PointerRoot) is generated on all root
windows
When a keyboard grab activates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Grab are generated (as for Normal
above) as if the focus were to change from F to G
When a keyboard grab deactivates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Ungrab are generated (as for
Normal above) as if the focus were to change from G to F
KeymapNotify
keys: LISTofCARD8
The value is a bit vector, as described in QueryKeymap. Reported to
clients selecting KeymapState on a window. Generated immediately after
every EnterNotify and FocusIn.
Expose
window: WINDOW
x, y, width, height: CARD16
last-in-series: BOOL
Reported to clients selecting Exposure on the window. Possibly
generated when a region of the window becomes viewable, but might only
be generated when a region becomes visible. All of the regions exposed
by a given "action" are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
Expose events are never generated on InputOnly windows.
GraphicsExposure
drawable: DRAWABLE
x, y, width, height: CARD16
last-in-series: BOOL
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a destination region could not be computed due to an
obscured or out-of-bounds source region. All of the regions exposed by
a given graphics request are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
NoExposure
drawable: DRAWABLE
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a graphics request that might produce GraphicsExposure
events does not produce any. The drawable specifies the destination
used for the graphics request.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
VisibilityNotify
window: WINDOW
state: {Unobscured, PartiallyObscured, FullyObscured}
Reported to clients selecting VisibilityChange on the window. In the
following, the state of the window is calculated ignoring all of the
window's subwindows. When a window changes state from partially or
fully obscured or not viewable to viewable and completely unobscured,
an event with Unobscured is generated. When a window changes state
from a) viewable and completely unobscured or b) not viewable, to
viewable and partially obscured, an event with PartiallyObscured is
generated. When a window changes state from a) viewable and completely
unobscured or b) viewable and partially obscured or c) not viewable, to
viewable and fully obscured, an event with FullyObscured is generated.
VisibilityNotify events are never generated on InputOnly windows.
CreateNotify
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on the parent.
Generated when the window is created. The arguments are as in the
CreateWindow request.
DestroyNotify
event, window: WINDOW
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is destroyed. "Event" is the window on which the event was
generated, and "window" is the window that is destroyed.
UnmapNotify
event, window: WINDOW
from-configure: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from mapped to unmapped. "Event" is the window on
which the event was generated, and "window" is the window that is
unmapped. The from-configure flag is True if the event was generated
as a result of the window's parent being resized when the window itself
had a win-gravity of Unmap.
MapNotify
event, window: WINDOW
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from unmapped to mapped. "Event" is the window on
which the event was generated, and "window" is the window that is
mapped. The override-redirect flag is from the window's attribute.
MapRequest
parent, window: WINDOW
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a MapWindow request is issued on an unmapped window with
an override-redirect attribute of False.
ReparentNotify
event, window, parent: WINDOW
x, y: INT16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on either the old or
the new parent, and to clients selecting StructureNotify on the window.
Generated when the window is reparented. "Event" is the window on
which the event was generated, "window" is the window that has been
re-rooted, and "parent" specifies the new parent. The x and y
coordinates are relative to the new parent's origin, and specify the
position of the upper left outer corner of the window. The
override-redirect flag is from the window's attribute.
ConfigureNotify
event, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when a
ConfigureWindow request actually changes the state of the window.
"Event" is the window on which the event was generated, and "window" is
the window that is changed. If above-sibling is None, then the window
is on the bottom of the stack with respect to siblings; otherwise, the
window is immediately on top of the specified sibling. The
override-redirect flag is from the window's attribute.
GravityNotify
event, window: WINDOW
x, y: INT16
Reported to clients selecting SubstructureNotify on the parent, and to
clients selecting StructureNotify on the window. Generated when a
window is moved because of a change in size of the parent. "Event" is
the window on which the event was generated, and "window" is the window
that is moved.
ResizeRequest
window: WINDOW
width, height: CARD16
Reported to the client selecting ResizeRedirect on the window.
Generated when a ConfigureWindow request by some other client on the
window attempts to change the size of the window. The width and height
are the inside size, not including the border.
ConfigureRequest
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a ConfigureWindow request is issued on the window by
some other client. The geometry is as derived from the request. The
above-sibling is the sibling the window should be placed directly on
top of; if None, then the window should be placed on the bottom.
CirculateNotify
event, window: WINDOW
place: {Top, Bottom}
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is actually restacked from a CirculateWindow request. "Event"
is the window on which the event was generated, and "window" is the
window that is restacked. If place is Top, the window is now on top of
all siblings; otherwise it is below all siblings.
CirculateRequest
parent, window: WINDOW
place: {Top, Bottom}
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a CirculateWindow request is issued on the parent and a
window actually needs to be restacked. The window specifies the window
to be restacked, and place specifies what the new position in the
stacking order should be.
PropertyNotify
window: WINDOW
atom: ATOM
state: {NewValue, Deleted}
time: TIMESTAMP
Reported to clients selecting PropertyChange on the window. Generated
when a property of the window is changed. The timestamp indicates the
server time when the property was changed.
SelectionClear
owner: WINDOW
selection: ATOM
time: TIMESTAMP
Reported to the current owner of a selection. Generated on the window
losing ownership when a new owner is being defined. The timestamp is
the last-change time recorded for the selection.
SelectionRequest
owner: WINDOW
selection: ATOM
target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Reported to the owner of a selection. Generated when a client issues a
ConvertSelection request. The arguments are as in the request.
The owner should convert the selection based on the specified target
type. If a property is specified, the owner should store the result as
that property on the requestor window, and then send a SelectionNotify
event to the requestor using SendEvent. If the selection cannot be
converted as requested, the owner should send a SelectionNotify with
the property set to None.
SelectionNotify
requestor: WINDOW
selection, target: ATOM
property: ATOM or None
time: TIMESTAMP or CurrentTime
This event is only generated by clients using SendEvent. The owner of
a selection should send this event to a requestor when a selection has
been converted and stored as a property, or when a selection conversion
could not be performed (indicated with property None).
ColormapNotify
window: WINDOW
colormap: COLORMAP or None
new: BOOL
state: {Installed, Uninstalled}
Reported to clients selecting ColormapChange on the window. Generated
with value True for new when the colormap attribute of the window is
changed. Generated with value False for new when the colormap of a
window is installed or uninstalled. In either case, state indicates
whether the colormap is currently installed.
ClientMessage
window: WINDOW
type: ATOM
format: {8, 16, 32}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
This event is only generated by clients using SendEvent. The type
specifies how the data is to be interpreted by the receiving client;
the server places no interpretation on the type or the data. The
format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities, so that the server can correctly
byte-swap as necessary. The data always consists of either 20 8-bit
values or 10 16-bit values or 5 32-bit values, although particular
message types might not make use of all of these values.
SECTION 12. FLOW CONTROL AND CONCURRENCY
Whenever the server is writing to a given connection, it is permissible for
the server to stop reading from that connection (but if the writing would
block it must continue to service other connections). The server is not
required to buffer more than a single request per connection at one time. For
a given connection to the server, a client can block while reading from the
connection, but should undertake to read (events and errors) when writing
would block. Failure on the part of a client to obey this rule could result
in a deadlocked connection, although deadlock is probably unlikely unless the
transport layer has very little buffering, or unless the client attempts to
send large numbers of requests without ever reading replies or checking for
errors and events.
If a server is implemented with internal concurrency, the overall effect must
be as if individual requests are executed to completion in some serial order,
and that requests from a given connection are executed in delivery order
(i.e., the total execution order is a shuffle of the individual streams). The
"execution" of a request includes validating all arguments, collecting all
data for any reply, and generating (and queueing) all required events, but
does not include the actual transmission of the reply and the events. In
addition, the effect of any other "cause" (e.g., activation of a grab, pointer
motion) that can generate multiple events must effectively generate (and
queue) all required events indivisibly with respect to all other causes and
requests.
∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 11:20:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 11:15:28 PDT
Date: 11 Jun 87 11:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup committee
To: X3J13@Sail.stanford.edu
Message-ID: <870611-111528-1358@Xerox>
The cleanup committee has been hard at work. We have produced a number
of issues for presentation at the next meeting. I will mail drafts of
the issues which seem ready to release to this list over the next
several days. I will then mail out a summary. A hardcopy of the issues
will also be mailed to the X3J13 mailing list.
Discussion is still on-going in cl-cleanup. There are a few proposals
that are in the last rounds of revisions which we will try finalize in
the next few days.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:34:46 PDT
Date: 11 Jun 87 13:33 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-133446-1639@Xerox>
!
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Version 2 by Masinter
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
Rationale:
This clarification follows the intent of the original Common Lisp
designers.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
Benefits:
This clarification makes the semantics of an important primitive more
well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:03:36 PDT
Date: 11 Jun 87 13:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Line-fold: no
Message-ID: <870611-130336-1594@Xerox>
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be brief; leave testimonials and personal opinions to the discussion at the end. Be complete; do not expect someone else to fix or redesign parts. Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp symbols (DEFUN rather than Defun). I like it better if you write in the third person rather than first.
Issue: >>A short descriptive label, which starts with a name which occurs in the index of CLtL, and be a suitable symbol in the Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an ambiguity or case of under-specified situation in CLtL, where this ambiguity interferes with portability of code. CHANGE -- proposal for an incompatible change to the language. ADDITION -- proposal for a compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation unclear or unsatisfactory? Avoid describing the proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as possible what you are proposing. Ideally, this should take the form of text that could be dropped into CLtL or some new specification document. If necessary, propose a set of labelled alternatives here, rather than a single proposal. Each proposal must be a complete design; do not leave out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the issue. The code should stand alone, and preferably be suitable for incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is listed, discuss each issue separately here and in subsequent sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way? Survey independent Common Lisp implementations - preferably three or more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much implementation effort is required? Is public-domain code available? For pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc. should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:15:10 PDT
Date: 11 Jun 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-cleanup@sail.stanford.edu
Message-ID: <870611-131510-1611@Xerox>
!
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 at committee meeting 15-Mar-87
Version 3 Masinter 15-Mar-87
Version 4 by Fahlman, incorporate Dribble
Version 5 by Masinter, 29-May-87, revert to Version 3
Version 6 by Masinter, 5-Jun-87, minor formatting
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:07:51 PDT
Date: 11 Jun 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-OP-C (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870611-140751-1716@Xerox>
!
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Versions 2,3 by Pitman
5-Jun-87, Version 4 by Masinter (copy-editing)
11-Jun-87, Version 5 release to X3J13
(remove confusing paragraph)
Problem Description:
CLtL is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Test Case:
(EQUAL (FORMAT NIL "~C" #\Space) " ")
Rationale:
This was probably the intent of the Common Lisp designers.
It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as a
simplification.
Discussion:
The cleanup committee generally supports this clarification.
The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:
"I believe the error in CLtL is that it was not stated explicitly that
the `implementation-dependent abbreviated format' applies only to
characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as WRITE-CHAR for characters with
zero char-bits. I don't think we want to require ~C and write-char to
do the same thing for characters with bits."
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUN 87 13:27:34 PDT
Date: 11 Jun 87 13:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-132734-1630@Xerox>
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/26/87
Version 2 by cleanup committee 15-Mar-87 14:45:18
Version 3 by Masinter (format) 15-Mar-87 18:34:28
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to declare a variable without
initializing it. More importantly, though, DEFVAR is used by lots of
users in every implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee generally supports this clarification.
[Version 3 was distributed at the last X3J13 meeting. This version has
changed only to bring it in line with the current proposal format.]
∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:07:01 PDT
Date: 11 Jun 87 13:06 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-130701-1603@Xerox>
In most of these proposals, some earlier version was circulated to the
committee and explicitly voted on. In cases where there have been
editorial changes after the ballot, the edited version has been
circulated, but not necessarily endorsed.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:40 PDT
Date: 11 Jun 87 13:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-ATSIGN-COLON (Version 3)
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <870611-134340-1658@Xerox>
This was distributed at the last X3J13 meeting. The only changes have
been to bring it into the current proposal format.
!
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem Description:
CLtL describes the format op syntax as:
"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."
CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?
Proposal (FORMAT-ATSIGN-COLON:OK):
There is no required ordering between the @ and : modifier.
Rationale:
This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.
Current practice:
Most implementations accept these in either order. Some implementations
have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Conversion Cost:
Existing user code would be unaffected.
Aesthetics:
Leaving these unordered is slightly simpler conceptually.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:04:43 PDT
Date: 11 Jun 87 13:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Message-ID: <870611-130443-1598@Xerox>
The previous version went out without line breaks.
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the
issue. The code should stand alone, and preferably be suitable for
incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is
listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:20:43 PDT
Date: 11 Jun 87 15:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
Message-ID: <870611-152043-1809@Xerox>
This issue was distributed at the last X3J13 meeting. The only changes
were to remove a sentence about INTERN (which didn't belong in this
proposal) and to put it in the current proposal format.
!
Issue: IMPORT-SETF-SYMBOL-PACKAGE
References: IMPORT (CLtL p. 186)
Category: CLARIFICATION.
Edit History: Version 2 at committee meeting 15-Mar-87 15:19:23
Version 3 by Masinter 15-Mar-87 18:42:13
Version 4 29-May-87 by Masinter, remove confusing
"to further clarify".
Version 5 to X3J13
Problem Description:
The action of IMPORT on the home package of a symbol is not described
well; does it affects the "home package" of a symbol.
Proposal (IMPORT-SETF-SYMBOL-PACKAGE:YES):
IMPORT behaves as follows: if any symbol to be imported has no home
package (SYMBOL-PACKAGE returns NIL), then IMPORT sets the home package
of the symbol to the specified package being imported to.
Rationale:
Current practice:
Most Common Lisp implementations work this way.
Adoption Cost:
small -- it requires a simple rewrite if not done this way.
Benefits:
Without this proposal, there is confusion about how Common Lisp works,
and the risks that some new implementations will not work this way.
Conversion Cost:
None, as this describes current practice.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:27:51 PDT
Date: 11 Jun 87 15:27 PDT
From: Masinter.pa@Xerox.COM
Subject: (REVISION) Issue: PATHNAME-STREAM (Version 3)
TO: X3j13@sail.stanford.edu
Line-fold: NO
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-152751-1817@Xerox>
Version 2 of this proposal accidentally contained an odd sentence fragment under Conversion cost. Sorry.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (remove odd
odd sentence fragment)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement. CLtL says that a stream can be used as an argument and converted to a pathname, but pathnames only name files, not other sources or sinks of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that is or was open to a file. For example, it is an error to attempt to obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only thing that can be implemented without large changes to the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others may do something else, but since the proposal is to define this to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an error", no implementations need change.
Benefits:
Description of pathname functions will make more sense.
Conversion Cost:
None.
Aesthetics:
Makes language a little cleaner.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:06:30 PDT
Date: 11 Jun 87 15:06 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
TO: X3j13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-150630-1795@Xerox>
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: We believe no existing user code relies on any values.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:18:53 PDT
Date: 11 Jun 87 14:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
To: X3J13@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-141853-1738@Xerox>
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 3 11-Jun-87, for release
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:23 PDT
Date: 11 Jun 87 13:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
TO: X3J13@sail.stanford.edu
reply-To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-134323-1657@Xerox>
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: OMISSION
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
FLET.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:35:38 PDT
Date: 11 Jun 87 15:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PRINC-CHARACTER (Version 2)
TO: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-cleanup@sail.stanford.edu
Line-fold: NO
Message-ID: <870611-153538-183@Xerox>
!
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Problem Description:
CLtL is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
The cleanup committee generally supports this proposal.
Pitman thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:20:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:43:28 PDT
Date: 15 Jun 87 14:15 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870615-144328-103@Xerox>
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case, it becomes desirable to use packages to prevent
accidental name clashes among non-positional argument names of different
functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂16-Jun-87 2337 Masinter.pa@Xerox.COM
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:17:44 PDT
Date: 16 Jun 87 17:17 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.Edu
Message-ID: <870616-171744-109@Xerox>
This is the cover letter for the various proposals which have been
mailed to you. Hardcopy versions of all proposals will go out in
tomorrow's (U.S.) mail.
!
Dear X3J13 member:
Enclosed are several proposals from the cleanup committee for your
examination. The committee has been working hard via electronic mail.
For each proposal, there has been an average of 10-15 messages.
In most cases, the cleanup committee has explicitly endorsed the
proposal--i.e., we all think it is a good idea. In some cases, while we
generally agreed that the proposal is a good idea, we've wrangled over
the exact wording of the proposal and the discussion; in those cases,
while an earlier version was circulated among the cleanup committee, the
latest version is the sole responsibility of the author. In a few cases
(identified in the proposal) there has been disagreement on the proposal
itself, but we believed we should bring the matter to the attention of
the larger group, for discussion and guidance.
Listed below are all of the issues currently under consideration, with
an extremely brief description of the issue. If you want further
details, or want to join the cleanup committee, please let us know
(CL-CLEANUP@Sail.Stanford.edu). Issues whose writeup is included in
this mailing (and mailed electronically) are marked with a !. Issues
marked with * are nearly ready for release, but a final version is not
available. We hope to have versions of these at the X3J13 meeting.
!
! Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Not ready for release.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
! AREF-1D (Version 5/11 Jun 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Almost ready for release.
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 3 released.
Version 6 released 11-Jun-87.
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87.
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
In discussion, formal proposal not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 released 11-Jun-87.
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 3 released.
Version 4 (re-)released 11-Jun-87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Almost ready for release.
FORMAT-NEGATIVE-PARAMETERS
In discussion, formal proposal not yet submitted.
! FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 released 11-Jun-87.
! FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 released 11-Jun-87.
! IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 3 Released
Version 5 released 11-Jun-87.
! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
( &KEY arguments not in keyword package?)
Version 6 released 15-Jun-87.
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
! PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Released 11-Jun-87.
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
! PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Released 11-Jun-87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
REMF-DESTURCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS?)
In discussion, no formal proposal submitted.
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:07:38 PDT
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IF-BODY (Version 7)
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870616-170738-108@Xerox>
The cleanup committee had a great deal of difficulty attempting to
arrive at a version of this proposal which fairly outlined the issues.
I don't think we succeeded. While the issue itself is straightforward,
the way in which it came about, our procedures for handling
controversial cases, the manner in which summaries of opinions get
generated, etc. have been problematic. Hidden within this simple issue
are some more complex ones, with tradeoffs between compatibility and
extensions, simplicity and ease of use. As it stands, while we have
discussed reviewed numerous versions of this proposal, this version has
not been approved or endorsed by the cleanup committee as a whole.
Larry Masinter
!
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history:27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (add IF-BODY:NO)
17-Apr-87, Version 3 by Masinter(merge 1&2)
19-Apr-87, Version 4 by Pitman (misc editing)
27-Apr-87, Version 5 by Pitman (for balance)
13-Jun-87, Version 6 by Pitman (for brevity)
16-Jun-87, Version 7 by Masinter(for brevity)
Problem Description
CLtL defines the special form IF as taking either two or three
arguments. Some implementations extended IF to allow more arguments. In
those implementations, using the extended IF syntax will not generate a
warning. Code using the extended IF is not portable.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
according to CLtL is an error. Under IF-BODY:LEGAL, this would return
MORE.
Rationale:
This extension is convenient to use and is compatible with many current
implementations.
Current Practice:
According to CLtL, the test case, (IF NIL 'THEN 'ELSE 'MORE) "is an
error".
Some implementations already provide the proposed extension.
A few implementations provide alternate keyword-driven extensions that
are incompatible with the proposed extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF,
returning only the value of the third argument when the first argument
is false.
Benefits:
As long as some implementations provide this extension while others do
not, the portability goals of Common Lisp will suffer. Code developed
where these features are available is not typically discovered to be in
error until a port to some other implementation is attempted. At that
point, which is typically inconveniently late in the development cycle,
the developer may notice that code either does not compile (generates
syntax errors) or does not compile correctly (the additional forms are
quietly ignored and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
Adoption Cost:
In most implementations which don't already have this extension, making
this syntax legal is a matter of a fairly localized change to a finite
number of utilities which reason about programs (compiler, interpreter,
code walkers).
In some implementations which have incompatible extension strategies,
such as keyword-driven facilities, the cost may be slightly higher
because this is an incompatible change.
Aesthetics:
This issue has both pro and con sides. Opinions differ on how important
each of these arguments are. The following arguments have been made:
Pro: When there are multiple else clauses, the alternatives (IF test
then (PROGN else1 else2)) or (COND (test then) (T else1 else2 else3))
are cumbersome. A natural extension of IF provides economy of expression
in some circumstances. Experience in user communities where extended IF
is available show that few users object to its presence; most are happy
about the syntactic flexibility it provides. By allowing the extended
IF, the resolution of this controversial programming style issue is left
to the user rather than being forced by the language designers. Those
who prefer the symmetry of the (IF test then else) syntax are free to
use it as needed or even exclusively without infringing on the desires
of others who may wish to use the extended syntax.
Con: The (IF test then else) syntax is symmetric. The asymmetry of (IF
test then {else}*) syntax can be visually confusing. IF was intended to
be the simplest conditional form, from which all the others are built.
This proposal makes it more complex.
Discussion:
The cleanup committee had a great deal of difficulty with this issue,
primarily because of the many conflicting priorities it seems to
represent. It prompted a great deal of debate.
The committee found it nearly impossible even to arrive at a version of
the problem statement and proposal which could be endorsed as a fair
representation of the issue. In particular, this version has not been
endorsed or agreed upon by all members the committee.
Some members feel very strongly that this proposal should be adopted,
while others object violently, not only to the proposal but to the
manner in which it arose. How can we balance flexibility against
simplicity in the language syntax? How seriously should we consider
compatibility with current extensions to Common Lisp?
The problem with IF-BODY arose as a serious compatibility issue in
porting a major Common Lisp application (MACSYMA).
There was strong sentiment that the allowed variance of IF is a serious
barrier to portability, and wants to see it fixed. Those who support
this proposal believe it is the minimally disruptive way to fix the
problem. If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
There was concern about the potential precedent which could be set by
using compatibility concerns as a lever to introduce all kinds of
unwanted idiosyncratic extensions present in a few implementations.
It was suggested that the mere fact that some people like an extensionis
not sufficient reason to put it into the language, but is sufficient
reason to -discuss- putting it into the language.
It was noted that one of the original reasons for including IF in the
language was to have a simple primitive that can easily be recognized,
by people and by program-walkers alike, as being the simplest
conditional and not having implicit PROGNs as do WHEN, UNLESS, and COND.
The supporters argue that the language is already so cluttered that
worrying about such a tiny change to IF is unwarranted (e.g., consider
the complexity of LAMBDA). If the only concern was primitive simplicity,
we should just redefine the layer at which simplicity is achieved by
letting LISP:IF be a macro that expands into PRIMITIVE:IF which has
simpler semantics but which no one has to be stuck programming with (if
they don't want to). While users could make their own JDOE:IF macro that
has this extension, this is likely to be a such a common extension, it
should be adopted as part of the standard.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:51:21 PDT
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
Reply-to: CL-Cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870616-155121-101@Xerox>
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
I am distributing version 5, even though the full cleanup committee has
not read or commented on it. Scott Fahlman worked hard to produce
Version 5; I think Scott's summary of the issues and arguments is
excellent. However, to repeat, because of insufficient time, this
proposal does not reflect a consensus of opinion, either on the proposal
or on the form in which it is presented.
This version presents the two options the committee discussed the most
as alternatives. We hope to be able to discuss (and revise) this
proposal before the Boston meeting. The proposal has two parts, one
less controversial than the other. It is possible that the group will
decide to postpone the difficult issues and just vote on the simpler
one.
The writing up of these two options was not meant to preclude others.
One other proposal was discussed, which would require a symbol's
function cell to accept symbols and lambda expressions as well as true
functions and to return unchanged whatever was put there. We do not yet
have an exposition of this point of view.
Since Scott Fahlman won't be at X3J13, he included his own position at
the end.
Sincerely,
Larry Masinter
!
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs
the status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Two alternative proposals are presented here:
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION. Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
Proposal FUNCTION-TYPE:COERCING-REDEFINITION
This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.
RATIONALE:
Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.
The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.
Adoption Cost:
For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified
to deal with functions that are not lists (but from which the list form
can be easily reconstructed if necessary).
If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so. Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
BENEFITS:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
CONVERSION COST:
The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do. One impact on
user-level code would be a change in the operation of certain type
predicates. Such cases should be relatively easy to find and fix.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted. However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions. CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.
Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.
AESTHETICS:
Making the concept of a function well-defined will probably be perceived
as a simplification.
The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals. The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.
DISCUSSION:
This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions. Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.
Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION. The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.
Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal. They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.
Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.
White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.
Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems. He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.
Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.
Clinger has suggested that the strict form is preferable because it
makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.
∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
barmar
∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 11:50:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 14:49:41-EDT
Date: Wed, 17 Jun 1987 14:49 EDT
Message-ID: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
I see no big hole here.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
Here's the way I would re-code APPLY, using a macro. FUNCALL, et al,
would be treated in a similar way. The covnersion tool would simply be
a code-walker (or perhaps even an editor macro) that turns every APPLY
into COERCING-APPLY unless the argument being passed in is sitting right
there and its type can be determined at conversion time.
(defmacro coercing-apply (funarg &rest other-args)
`(apply (let ((x ,funarg))
(typecase x
(function x)
(symbol (symbol-function x))
(t (eval (list 'function x)))))
,@other-args))
Assuming that the implementation has a good implementation of TYPECASE
and a quick test for the FUNCTION data type, this should add very little
extra cost to the APPLY call, except in the case where a raw lambda-list
needs to be function-ized. Some smart compilers may optimize away a
TYPECASE statement if the type of the object can be determined by
analysis at compile time.
Note that COERCING-APPLY is almost identical to what APPLY would look
like in the coercing version of the proposal, except that the
type-dispatch and coercion is outside the APPLY rather than inside.
Anyone arguing that the strict form of the proposal is unacceptable
because this fully-mechanized method of conversion introduces
inefficiency should realize that this same inefficiency is currently
built into *every* FUNCALL and APPLY, and would continue to be under the
coercing version of the proposal. Under the strict form, it only
appears in mechanically converted code, and then only in cases where the
type of the functional argument is not easily determined at
conversion/compile time. But I think that the overhead is so small
compared to an APPLY-type function call that efficiency is not a strong
argument for either side.
If code size is a bigger issue than the speed of APPLY, COERCING-APPLY
could be coded as a function rather than as a macro, or it could be done
as an inline function, letting the user control the tradeoff via
declarations. There are very few programs around in which the code size
would grow by more than 1%, even in the macro case.
So, fully mechanized conversion of old code is feasible under the
STRICT-REDEFINITION proposal. The question is whether we are willing to
accept even this small inconvenience in order to get a cleaner language
(if indeed you believe that the strict form is cleaner).
-- Scott
∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Jun 87 12:46:48 PDT
Received: from polycarp by Think.COM via CHAOS; Wed, 17 Jun 87 15:49:07 EDT
Date: Wed, 17 Jun 87 15:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
Cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Message-Id: <870617154704.1.BARMAR@POLYCARP.THINK.COM>
Date: Wed, 17 Jun 1987 14:49 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
I now agree with this.
As for whether MAKE-FUNCTION should be added, I still think it should
be. If STRICT-REDEFINITION is adopted, then programmers who want to
turn lambda lists into functions will need a reasonable way to do this.
Yes, (EVAL `(FUNCTION ,LAMBDA-LIST)) will do it, but I don't think users
should have to write this. Generally, Lisp programmers are taught that
they should rarely need to invoke EVAL directly, unless they are
implementing an embedded language or something along those lines.
Consider the function:
(defun read-apply-print-loop ()
(loop (print (apply (make-function (read)))))
This isn't an embedded language, and there's no reason it should have to
call EVAL directly.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
I don't agree that this is a temporary crutch only for old code. There
is no way to write the above function without manually coercing lambda
lists to functions, because the lambda list that it is trying to apply
did not come from another program, it was generated on the fly (in this
case by the reader). There is no way for read to return a function
object (actually, there is a disgusting way, q.v.), it can only return a
lambda list.
Here's the disgusting way to make READ return a function: the user can
type "#.#'(lambda ...)".
barmar
∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.
CONVERSION COST:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.
∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 17:40:16 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 20:39-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 47846; 17 Jun 87 20:38:56-EDT
Date: Wed, 17 Jun 87 18:32 EDT
From: Mike%acorn@oak.lcs.mit.edu
Subject: updcoming meeting
To: x3j13@sail.stanford.edu
Message-ID: <870617183245.1.MIKE@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Sorry if you received this twice.
To: x3j13 participants
From: Gold Hill Computers
163 Harvard St.
Cambridge, MA 02139
617-492-2071
Gold Hill is handling the arrangements for the meeting
on June 30 and July 1.
The MIT/AI Lab has graciously offered to provide space
for the meetings on the 8th floor at 545 Technology Square,
Cambridge MA. In addition, classroom space for sub-committee
meetings on June 29 is also being provided. Room numbers
are as follows: 512, 516, 204, and 773.
Arrangements with the Cambridge Marriott Hotel for rooms
at a special rate of $115 have been arranged.
Contact Dana at Gold Hill about these rooms.
Arrangements have also been made with Delta Airlines for a
special fare. This will be a 30% discount on "Selling Y"
fares. It can apply to either coach or special coach fares.
Reservations must be made at least seven days in advance.
To use this discount, call Delta at 1-800-641-6760.
The identifying file number is A1680. The identifying
name is X3J13.
There will be a charge of $40 for each participant for
catering services provided for breakfast pastry,
coffee and lunch for both days.
My apologies about the late notifications.
Dana Kawiecki
Coordinator.
P.S., we regret that due to network failures, there is no
reliable way to contact Gold Hill by electronic mail at the
present time.
∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 20:11:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 23:10:30-EDT
Date: Wed, 17 Jun 1987 23:10 EDT
Message-ID: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: IF-BODY (Version 7)
In-reply-to: Msg of 16 Jun 1987 20:07-EDT from Masinter.pa at Xerox.COM <CL-CLEANUP at Sail.stanford.edu>
Since I will not be able to atend the X3J13 in Boston, I would like to
state my views on this proposal via mail. This message may also help to
explain what the "disagreements within the cleanup committee" were all
about.
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so. I think that it is
confusing to see something like
(IF pred-clause
clause-1
clause-2
clause-3
and-so-on)
in a program. The then-clause gets lost in all the clutter, and it is
harder to understand the program in a quick scan. If there
must be multiple else-clauses, I prefer to see something like
(IF pred-clause
(PROGN then-clause-1
then-clause-2)
(PROGN else-clause-1
else-clause-2
and-so-on))
The two distinct conditional branches jump out at you in this case.
Since this extension would affect my ability to READ Common Lisp code,
it is little consolation that I don't have to use the new construct
myself.
Another problem with the proposed extension: If one is allowed only one
"then" clause but multiple "else" clauses, some users will be tempted to
negate the test in order to get the more complex result into the "else"
position. Again, this makes code harder to read and understand. It is
no big thing, but neither is an occasional PROGN.
Well, so much for my own sense of aesthetics. If the members of X3J13
disagree -- if they really feel that the proposed extension improves
Common Lisp -- then so be it.
The real disagreement concerned the other argument in the proposal. It
goes roughly like this: Some manufacturers have unilaterally adopted
this extension. Their users get screwed when they move their code into
Common Lisp systems without this extension. The extension is compatible
and relatively innocuous. Therefore, we should force every Common Lisp
to adopt this extension so that these poor users won't have to suffer.
Or, if we are unwilling to do that, we must explicitly outlaw this
extension. (Clever straw-man, that.)
I think that it would be a very dangerous precedent if we were to give
this argument any weight whatsoever. This same line of argument could
be used to smuggle all sorts of idiotic extensions into the language.
It has always been an important principle of Common Lisp that
implementation-specific extensions are allowed; we would never have
reached agreement if this were not the case. So it would be wrong to
outlaw the extended form of IF. But code that makes use of non-portable
extensions is not portable, and its users should not expect it to be.
Vendors of extended Common Lisp systems should make life easy for the
developers of portable code by providing a compiler mode that warns
about non-standard usage. In the case of extended IF, this would be
very easy, and the fix is equally easy: just add a PROGN. So if users
really are experiencing the portability problems described in this
proposal, they should ask the manufacturer of the system they are using
to provide such a tool. That is the right way to handle portability
problems caused by non-standard extensions. If the manufacturer doesn't
think the portability problem is serious enough to fix, why should we
change the language to make this system's users more comfortable?
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
Anyway, that's what the disagreement was about, along with much
procedural discussion about how much of this debate should appear in the
proposal and about whether the proposal should go out at all.
-- Scott
∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 07:36:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Jun 87 10:35:41-EDT
Date: Thu, 18 Jun 1987 10:35 EDT
Message-ID: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 17 Jun 1987 16:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In response to Moon:
I tried to respond to this yesterday, but it looks like the mail system
ate my message. My apologies if anyone sees this twice.
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
-- Scott
∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 08:21:26 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA00828; Thu, 18 Jun 87 09:23:09 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12575; Thu, 18 Jun 87 09:23:06 MDT
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8706181523.AA12575@orion.utah.edu>
To: x3j13@sail.stanford.edu
Subject: IF with multiple ELSE
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 18 Jun 87 09:13:25 PDT
Received: from OCCAM.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 33136; Thu 18-Jun-87 12:16:18 EDT
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: IF-BODY (Version 7)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Message-ID: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 17 Jun 1987 23:10 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so.
I'm not going to discuss the esthetics of the change, but I agree with
Scott that we shouldn't change IF (even though I occasionally use
multiple else-clauses in my own programs, but most of them make
extensive use of Symbolics OS features already, so they are not
portable).
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
There's been quite a bit of discussion about how to deal with extensions
before, and I'm going to restate my opinion.
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
(SI:DEFINE-SPECIAL-FORM LISP:IF
IF-EXPANDER (PRED THEN ELSE)
...)
(SI:DEFINE-SPECIAL-FORM SCL:IF
IF-EXPANDER (PRED THEN &REST ELSES)
...)
Portable applications would normally be written in packages that :USE
LISP, while non-portable applications could :USE SCL.
I realize that the package scheme doesn't solve all problems with
extensions, but it can go a long way. It could be used to solve this
problem, as well as LOOP (unless and until the fancy LOOP macro is
adopted).
barmar
∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 10:01:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176524; Thu 18-Jun-87 12:59:36 EDT
Date: Thu, 18 Jun 87 12:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Message-ID: <870618125936.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 1987 10:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In response to Moon:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
Scott, the "automatic strategy" sentence that I quoted out of context
was in the context of discussing how to put in run-time type tests.
∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 17:40:51 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 226953; Thu 18-Jun-87 20:24:59 EDT
Date: Thu, 18 Jun 87 20:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: Barry Margolin <barmar@AQUINAS.THINK.COM>
cc: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>, X3J13@sail.stanford.edu
In-Reply-To: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Message-ID: <870618202441.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
This doesn't work so well if there are any applications or any part of
CL that uses that symbol for EQness. For example, if I ran an application
that used 'IF as part of the protocol for interfacing to it, and it was
written in strict CL (and was therefor loaded into our LISP: package)
and I wanted to use it from SCL, things would start getting very confusing.
If you're just dealing with a single application, however, this works so
long as the symbol isn't one of the few symbols that CL uses the EQness
of (such as DOCUMENTATION, VARIABLE, EVAL, COMPILE, LOAD, EQ, EQL, EQUAL,
&ALLOW-OTHER-KEYS, &AUX, &BODY, &ENVIRONMENT, &KEY, &OPTIONAL, &REST, or
&WHOLE.
You also screw up importing any "portable" program-understanding code
that knows anything about that symbol. (Program-understanding code
is not necessarily some big thing that knows the whole language; SETF
is a much smaller example).
In general, shadowing has a lot to disrecommend it as a strategy for
extending Common Lisp.
These comments don't apply, however, to sub-environments intended
directly for developing and testing code intended to be strictly
portable.
∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 23:50:14 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227051; Fri 19-Jun-87 02:49:51 EDT
Date: Fri, 19 Jun 87 02:49 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Stanley T. Shebs <shebs%orion@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706181523.AA12575@orion.utah.edu>
Message-ID: <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
On the contrary! This is not an issue of compatibility with
older dialects. There are two reasons:
1) Convenience. Several modern dialects have it because we find it
very convenient to use.
1a) Inconvenience of the alternative. PROGN hastens your indentation's
march to the right edge of your screen.
2) Compatibility with those *modern* dialects which choose to extend
IF in this way.
The issue isn't compatibility with older dialects; I agree that can take
a back seat.
While I'm at it, I may as well point out that many of us who use the
extended IF indent it in a way that the THEN and ELSE clauses are
readily distinguished. I find
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
confusing, even without additional ELSE forms, especially if the
condition form is longer than one line. I prefer
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
I think this would render the "readability" argument irrelevant,
except there are those who dislike this for reasons I've never
fathomed. (But let's not debate what the best indentation is
here, please! I'm just pointing out the alternative).
∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87 21:00:21 PDT
Received: by navajo.stanford.edu; Fri, 19 Jun 87 20:57:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05237; Fri, 19 Jun 87 20:35:00 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05585; Fri, 19 Jun 87 20:37:23 PDT
Date: Fri, 19 Jun 87 20:37:23 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706200337.AA05585@bhopal.edsel.uucp>
To: navajo!RWK%YUKON.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!shebs%orion%cs.utah.edu@navajo.stanford.edu,
navajo!x3j13%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Robert W. Kerns's message of Fri, 19 Jun 87 02:49 EDT <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
This may be a hopeless quest but . . .
Why is there so little interest in having a conditional form for CL that
more closely approximates the standard computer-science language conditionals
(for "standard .. languages", read "Algol-like").
Interlisp has a format that many use and love:
(if <condition1>
then <clause11> <clause12> ... <clause1n1>
elseif <condition2>
then <clause21> <clause22> ... <clause2n2>
. . .
else <clausem1> <clausem2> ... <clausemnm>
)
and I think Franz Lisp added this format in an essentially upward-compatible
way. The only flaw with such an extension is that the word THEN can't be
used as an ordinary then clause by itself [but then again, how many times
does "then" or "else" appear as local variables, in programs like
(if <mumble> then 5)
where the ambiguity is apparent].
Isn't Common Lisp really much less than "modern" by providing only the
crude form (if <form1>
<form2>
<form3>)
as the primary conditional paradigm?
-- JonL --
∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87 22:04:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177997; Sat 20-Jun-87 01:02:55 EDT
Date: Sat, 20 Jun 87 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706200337.AA05585@bhopal.edsel.uucp>
Message-ID: <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Use COND.
If you don't like the parentheses, use M-expressions.
∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jun 87 04:37:26 PDT
Received: by navajo.stanford.edu; Sat, 20 Jun 87 04:34:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05823; Sat, 20 Jun 87 03:24:42 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05994; Sat, 20 Jun 87 03:27:06 PDT
Date: Sat, 20 Jun 87 03:27:06 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706201027.AA05994@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!x3j13%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 20 Jun 87 01:02 EDT <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
Re: Use COND.
If you don't like the parentheses, use M-expressions.
Is this a reply to the query "Why is Common Lisp aping ALGOL, but
winding up blatantly idiosyncratic, and for no useful reason"? If
so, then it it may well be interpreted as
Use FORTRAN (has 1950's level syntax, just like COND)
If you don't like the 80-column lines, use PascaModulADAlgolC
-- JonL --
∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 21 Jun 87 16:51:00 PDT
Received: by ucbarpa.Berkeley.EDU (5.57/1.25)
id AA07095; Fri, 19 Jun 87 23:30:13 PDT
Received: from frisky by franz (5.5/3.14)
id AA29568; Fri, 19 Jun 87 23:20:19 PDT
Received: by frisky (3.2/3.14)
id AA13854; Fri, 19 Jun 87 23:15:50 PDT
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8706200615.AA13854@frisky>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
x3j13@sail.stanford.edu
Subject: Re: IF with multiple ELSE
In-Reply-To: Your message of Sat, 20 Jun 87 01:02:00 EDT.
<870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 19 Jun 87 23:15:49 PDT
>> Use COND.
Did you forget the little smiley face?
I've got a lot of experience using a if form with 'then', 'elseif' and
'else' clauses and I'd rate it about an order of magnitude more
readable than cond. I'd also rate 'cond' about a half order of
magnitude more readable than the common lisp 'if' (which is downright
unreadable).
∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 09:35:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94385; Mon 22-Jun-87 12:03:15 EDT
Date: Mon, 22 Jun 87 12:02 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: edsel!bhopal!jonl@navajo.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8706200615.AA13854@frisky>
Message-ID: <870622120219.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 10:13:04 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA02476; Mon, 22 Jun 87 10:09:34 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA07547; Mon, 22 Jun 87 10:08:51 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
id AA05089; Mon, 22 Jun 87 10:12:52 PDT
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8706221712.AA05089@clam.sun.com>
To: DLW@ALDERAAN.SCRC.Symbolics.COM
Subject: Re: IF with multiple ELSE
Cc: x3j13@sail.stanford.edu
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:12:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94440; Mon 22-Jun-87 14:12:04 EDT
Date: Mon, 22 Jun 87 14:11 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: cperdue@Sun.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-ID: <870622141115.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Let's pursue this issue further.
The only point I was trying to make is that I don't think that it will
be valuable to continue to discuss this over the X3J13 mailing list.
∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:23:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 22 Jun 87 14:12:18-EDT
Date: Mon, 22 Jun 1987 14:12 EDT
Message-ID: <FAHLMAN.12312578230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: IF with multiple ELSE
In-reply-to: Msg of 22 Jun 1987 13:12-EDT from cperdue at Sun.COM (Cris Perdue)
Regarding the (if ... then ... else ...) proposal:
This is the same rock on which every attempt to come up with a LOOP-like
construct has run aground: some people like the Interlisp/MIT-Loop-macro
style in which you have lengthy flat lists punctuated with reserved
symbols that play a syntactic role; others hate this and prefer a
"Lispy" syntax in which nested list structure is used to organize the
clauses and parts of a clause. I suppose that if we decide to swallow
the "psuedo-English" syntax for LOOP, then (if ... then ... else
...) is a natural thing to add as well. I suppose that one of these
days we will have to come to grips with this whole bag of worms again --
isn't there a committee working on this?
The current form of IF looks just fine to me, but that is probably a
matter of having seen so many of them. I once saw some code by Joe
Ginder (don't know if the idea was original with him or not) that simply
defined THEN and ELSE as macros that expand into PROGN of the same body.
Once can then write
(if <predicate>
(then clause
clause ...)
(else clause
clause ...))
A perverse programmer could really confuse things by switching the THEN
and ELSE symbols, but perverse programmers can write obscure code in any
event.
-- Scott
∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:07:29 PDT
Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 15:07:19 EDT
Date: Mon, 22 Jun 87 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: IF with multiple ELSE
To: Cris Perdue <cperdue@sun.com>
Cc: DLW@alderaan.scrc.symbolics.com, x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-Id: <870622150454.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@sun.com (Cris Perdue)
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
Unless someone plans on doing some human factors experiments, we will
not be able to make any objective decision about the "readability,
clarity, and error-proneness issue". The matter of taste that Dan
referred to was the fact that different people find the different forms
more readable, clear, or error-prone. Without concrete data, taste is
all we can go by. What we've seen so far is lots of people saying,
"well, I've been using FOO-LISP's WHIZ-BANG-IF feature for years, and
it's really great." Lots of people swore by Interlisp's DWIM feature,
but it wasn't put into CL either.
barmar
∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:10:43 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA09296; Mon, 22 Jun 87 13:12:32 MDT
Date: Mon, 22 Jun 87 13:12:32 MDT
From: shebs@cs.utah.edu (Stanley Shebs)
Message-Id: <8706221912.AA09296@cs.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Purpose of this Mailing List
What exactly is this mailing list for? It's pretty clear that arguments
will be carried on anywhere that they are not specifically forbidden.
To reduce traffic, this list should be one-way from committees to everybody
else, with all replies going to committees again, or else each individual
is allowed one public response to any single proposal from a committee.
stan
∂23-Jun-87 1104 RPG Meeting Room at MIT
To: x3j13@SAIL.STANFORD.EDU
Several people have pointed out to me that the 8th floor of 545 Tech
Square must be the AI Lab playroom. I had not really thought about where
the meeting might be held, and when I investigated further, I found out it
was indeed the playroom. The playroom, though colorful, is not an appropriate
place to meet because it is surrounded by the open doors of offices.
The person at Gold Hill who made the arrangements is out of town this
week, so I asked Rod Brooks to look into the situation. He found out that
the playroom was booked for Monday and Tuesday of next week. He reserved
6-120 (Building 6, room 120), which seats 175, for Tuesday and Wednesday
of next week for us. This room is in the eastern leg of the large
U-shaped building with the dome at the bottom and whose open end faces the
Charles river.
Since it might be that the current arrangements are for the wrong two days,
the catering plans might need to be altered, but I am unable to do that
until I can reach someone at Gold Hill.
I am leaving for Boston Friday morning, and, unless I can provide more
information before I leave, you ought to visit the playroom on the
8th floor when you arrive to find out where the meeting will really
be held.
-rpg-
∂25-Jun-87 2342 RPG Meeting Room
To: x3j13@SAIL.STANFORD.EDU
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87 10:48:07 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 12:46:34-CDT
Date: Fri, 26 Jun 87 12:46 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Meeting Room
To: x3j13%SAIL.STANFORD.EDU@MCC.COM
cc: Loeffler@MCC.COM
In-Reply-To: <8706260705.AA01887@bell>
Message-ID: <870626124601.5.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: 25 Jun 87 2342 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
Would someone please see that maps are provided at the hotel for those
that do not know how to navigate the MIT campus.
-- David D. Loeffler
∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 30 Jun 87 11:08:22 PDT
Date: Tue, 30 Jun 87 18:55:53 BST
From: Richard Barber (ProcyonResearch) <procyon@Cs.Ucl.AC.UK>
To: x3j13@sail.stanford.edu
cc: mathis@c.isi.edu
Subject: Common Lisp Mailing List
We now have an ARPANET address. Please can you add us to the X3J13 mailing
list.
We haven't had any mailings from the committee for quite a while now. Perhaps
you haven't received our subscription?
Richard Barber
Procyon Research Limited
England.
∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:48:48 PDT
Date: 2 Jul 1987 06:14-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: BALLOT! ISO NWI
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 2-Jul-87 06:14:29.MATHIS>
This is to inform/remind all of you that there will be a mail
ballot on the ISO New Work Item on Lisp. This was distributed
and discussed at the recent meeting in Cambridge. There will be
a very short respose time. Expect to see something on the net
this weekend and in your physical mail next week. -- Bob
∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jul 87 18:03:19 PDT
Date: 5 Jul 1987 18:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: DRAFT letter and ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jul-87 18:02:46.MATHIS>
What follows is a DRAFT of my letter and the X3J13 ballot
on the ISO New Work Item. This is not! the final version.
It is being sent to you for comment and advance notice.
Please comment within two days. -- Bob
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 1
Doc. No.: X3J13/87-030
Date: 87-07-06
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathisda20.isi.edu
X3J13 Members and Mailing List Observers:
ACTION REQUIRED -- This mailing includes a mail ballot which must
______ ________
ACTION REQUIRED
______ ________
be returned by active US members of X3J
DEADLINE: NOON, July 28, 1987
________
DEADLINE
________
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, o
them to myself.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 19206-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. In being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people ant to say. Our electronic mailing list
(X3J13s available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 2
I must have our response to X3 by July 29, 1987. I intend to take
it to them personnally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which was previously approved by
X3.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 3
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written so as to go with
either a positive or negative vote on whether the description of
the NWI is sufficient or not. This paragraph was not reviewed at
the meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
________ ________
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfer with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 4
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
__________
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
ballot. This letter is being sent to everyone on the X3J13
mailing list which includes many people who are likely to be on
the ISO working group; so these comments and concerns are being
made known. The issue is primarily whether or not they will be
made a part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
1. yes 2. yes 3. no
1. yes 2. yes 3. yes
1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.)
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 5
As to the other items on the ballot (Q.3 -- Q.7) the answers are
all "YES." [Q.3] The US is prepared to actively participate in
this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
_________________________
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathisda20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 6
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
_________
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
__________
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
__________
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on page
__________
3 of X3J13/87-030 be attached as formal comments with the US
response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO" to
the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
There are some transmission errors in the above text; but I hope
it shows the main essence of the topic. -- Bob
∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Jul 87 20:19:37 PDT
Date: 12 Jul 1987 20:19-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Jul-87 20:19:06.MATHIS>
Doc. No.: X3J13/87-030
Date: 87-07-12
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathis@Ada20.isi.edu
X3J13 Members and Mailing List Observers:
IMMEDIATE ACTION REQUIRED -- This mailing includes a mail ballot
which must be returned by active US members of X3J13.
DEADLINE: NOON, July 28, 1987 ELECTRONIC RESPONSE POSSIBLE (p. 4)
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, or keep
them to myself. Since the issue relates to the US position on an
ISO ballot, the US principal members of X3J13 are the ones who
must vote and who will determine the result.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 1929)" (X3/87-06-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13. A draft of this letter and
ballot was distributed electronically for preliminary comment on
July 5, 1987.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. Being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people want to say. Our electronic mailing list
(X3J13@SAIL. Stanford.edu) is available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
I must have our response to X3 by July 29, 1987. I intend to take
it to them personally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which X3 previously approved.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written to go with either a
positive or negative vote on whether the description of the NWI
is sufficient or not. This paragraph was not reviewed at the
meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opinions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
vote. This letter is being sent to everyone on the X3J13 mailing
list which includes many people who are likely to be on the ISO
working group; so these comments and concerns are being made
known. The issue is primarily whether or not they will be made a
part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
First Option: 1. yes 2. yes 3. no
Second Option: 1. yes 2. yes 3. yes
Third Option: 1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.) If you want to choose
one of these options, you can respond electronically on this
ballot to Mathis@Ada20.isi.edu.
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
As to the other items on the ISO ballot (Q.3 -- Q.7) the answers
are all "YES." [Q.3] The US is prepared to actively participate
in this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathis@Ada20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
(electronic response possible see p. 4)
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on
page 3 of X3J13/87-030 be attached as formal comments with the
US response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO"
to the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:01 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05324; Fri, 17 Jul 87 12:30:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00277; Fri, 17 Jul 87 12:34:45 PDT
Date: Fri, 17 Jul 87 12:34:45 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171934.AA00277@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: "Iteration" activity
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
The large LOOP document I informally passed out at the Boston meeting
is a "reference" manual, and as such was intended for scrutiny by those
who are already are MIT-style LOOP lovers. Unfortunately, it seems to
be too much to digest for the novice, so I've prepared a 1-page "Blurb"
and a 1-page "Crib Sheet" to assist the kind of person who doesn't want
to be a LOOP wizard, but may want to have a working knowledge of it
[e.g., to read other people's code, or just to understand this common
but not universal iteration paradigm].
I would like to put this short document formally before the committee
as a readable report on the syntax and semantics of the MIT-style LOOP.
The next message from me to X3J13 will be three pages which are the text
of a "Blurb" (short, working-knowledge overview), a "Crib Sheet" (BNF
syntax with examples for most usages), and a set of two larger examples.
These three pages would be "hardcopied" by printing the "Blurb" in two
columns, 72 lines per column, landscape orientation, on one side of a
sheet, with the "Crib Sheet" similarly printed on the other side. The
"LOOP Examples" page may be viewed as a pop quiz, to see if you can
actually read production-level LOOP code.
Other iteration committee members have indicated they would submit some
additional material for X3J13 consideration, but time constraints seem to
have postponed them [e.g., Chris Perdue wanted to describe an Alphard-
style system, and Pavel Curtis had some ideas on changing or extending
the "collector" syntax of the MIT-style LOOP]. There is also some
question about whether or not to put the LETS reference manual and
code into the X3J13 arena; its size is comparable to that of LOOP, and
as yet we don't have any serious advocates for it on the committee.
-- JonL --
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:15 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:58 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05329; Fri, 17 Jul 87 12:32:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00290; Fri, 17 Jul 87 12:36:46 PDT
Date: Fri, 17 Jul 87 12:36:46 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171936.AA00290@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: LOOP "Blurb & Crib Sheet"
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
LOOP Iteration Macro BLURB
WHAT IT IS:
LOOP syntax is an extension of the Common Lisp LOOP macro (CLtL, p 121), and
is expanded into other simpler Common Lisp primitives; the LOOP facility may
thus be thought of as a parser (or as a compiler) into more primitve lisp.
Parsing is controlled by Loop token words, which are simply symbols like FOR,
UNTIL, MAXIMIZE etc. A list of the more common Loop token words, along with
their syntax of usage, appears in the attached "CRIB SHEET".
HOW TO PARSE (and "READ") LOOP CLAUSES:
Each syntactic part of a LOOP construct is called a "clause," whose scope
is determined by the top-level parsing of the Loop token words. This
example contains a few of the possible clauses, to be explained below:
(LOOP FOR i FROM 1 TO (compute-top-value) ;first clause
WHILE (not (unacceptablep i)) ;second clause
COLLECT (square i) ;third clause
DO (format t "Working on ~D now" i) ;fourth clause
WHEN (evenp i) ;fifth clause
DO (format t "~D is a non-odd number" i)
FINALLY (format t "About to exit!!")) ;sixth clause
FROM and TO are also Loop token words, but they are auxiliaries to the FOR
clause. Just how many forms comprise a clause depends on the Loop token
word that starts the clause and on the auxiliary tokens connected with it.
ORDER OF EXECUTION:
Except as noted below, clauses are executed in the same order as they appear
in source code, just as if they were inside one big PROGN. This is repeated
over and over until some clause causes termination, or until a Lisp RETURN,
GO, or THROW, is executed. The exceptions to "linear order" are:
-- Variable initializations are all done first, regardless of where in
the loop body the clause that established the variable is located.
-- The INITIALLY clause (if any) is executed once, before cycling
through the rest of the code.
-- The FINALLY clause (if any) is executed once, before exiting, except
when the code is exited by a Common Lisp GO, RETURN, or THROW.
(Another exception is THEREIS/ALWAYS/NEVER clauses; see the Loop
reference manual for details).
-- Clauses labeled "Iteration Control" (such as FOR i from 1 to 10 ...)
implicitly cause:
+ a variable initialization to be done "initially";
+ a variable "stepping" to be done, generally, between
each execution of the PROGN-like loop body; and
+ a termination test to be performed, generally, just
before the execution of the loop body.
KINDS OF LOOP CLAUSES:
Clauses turn into Lisp code that falls into one of several categories:
** Variable initializating and possibly incrementing:
-- FOR (and its synonym AS) establish a variable to be initialized.
These are called "Iteration control" clauses, and are further
distinguished by auxiliary tokens such as IN, BY, FROM, etc.
FOR/AS clauses also produce code to re-initialize the variable
each time around the loop. When used with the auxiliary "=",
the same form used for the first initialization code is used for
the re-initialization code. With any auxiliary like FROM, UPTO,
DOWN, etc. the re-initialization is a numerical increment by INCF
(or by DECF) defaulting to 1, but changeable by auxiliary BY.
-- Multiple FOR/AS clauses may be combined either serially or
sequentially with the token AND (This is an advanced topic --
see the Loop reference manual for details.)
-- WITH is basically equivalent to a single LET clause. Multiple
WITH clauses may be combined either serially or sequentially
using the token AND (see the Loop reference manual for details).
** Value accumulation
-- COLLECT takes just one form in its clause, and tacks the value
of that form onto the end of a list of values to be returned
when the loop finishes.
-- APPEND is like collect except the value is considered to be
a list of zero or more individual values to be tacked on.
-- SUM takes just one form in its clause, which must evaluate to a
number; the sum of the numbers is returned when the loop finishes.
-- COUNT takes just one form in its clause, and counts the times it
evaluates to non-nil; the count is returned when the loop finishes.
-- MINIMIZE takes just one form in its clause, and keeps track of the
minimum value attained by evaluating that form; this minimum value
is returned when the loop finishes.
-- MAXIMIZE (similar to MINIMIZE).
-- THEREIS, explained below, will cause the non-null value of its
termination predicate to be returned; **however** termination
may occur due to some other clause, in which case the THEREIS
clause does not affect anything.
-- <...>ING -- most of these token words can also be suffixed with ING
** Termination conditions
-- (LOOP-FINISH) is a macro (rather than a token word or clause)
essentially equivalent to a RETURN out of the loop. However,
an accumulated value (if any) is returned instead of nil, and a
FINALLY clause (if any) is also executed.
-- FOR/AS clauses contribute a termination test determined by
the nature of the "Iteration control"
-- WHILE takes just one form, <condition>, in its clause and is
equivalent to the code: (if (not <condition>) (loop-finish)).
-- UNTIL is an inverse of WHILE: (if <condition> (loop-finish)).
-- THEREIS, like UNTIL, takes just one form in its clause, and causes
termination whenever that form evaluates to non-nil; unlike UNTIL,
it does not call (LOOP-FINISH), but directly returns the non-null
value from its form.
-- ALWAYS is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "false" (i.e., nil).
-- NEVER is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "true" (i.e., non-nil).
** Unconditional execution
-- DO clauses include all forms up to the next Loop token word;
they are all executed each time around the loop body.
-- DOING is a synonym for DO.
** Conditionals
-- IF clauses take one form as a predicate, and a subsequent value
accumulation clause (or DO or nested conditional clause) that
is executed during the loop body phase if the predicate is true.
-- WHEN is a synonym for IF.
-- UNLESS is like WHEN, but complements the predicate.
-- an ELSE clause is an optional component of an IF, WHEN, or UNLESS
clause, and is executed when the predicate is false.
KINDS OF ITERATION CONTROLS
** Iterating over integers, including or not including the endpoint:
(loop for i from 1 to 10 do ...) ;range includes 1, 2, ... and 10
(loop for i from 1 below 10 do ...) ; includes 1, 2, ... but not 10
(loop for i upto 10 do ...) ; includes 0 (default) ... and 10
(loop for i from 10 above 1 do ...) ; includes 10, 9 , 8 ... but not 1
(loop for i below 10 do ...) ; includes 0 (default) ... not 10
** Iterating over lists
(loop for item in baz-list do ...) ;somewhat like dolist
(loop for tail on baz-list do ...) ;somewhat like maplist
(loop for item in baz-list by #'cddr do ...) ;skips alternate items
** Iterating over Common Lisp sequences (access via ELT):
(loop for a being the elements of <some-sequence> ...)
** Repeated setting of variable to same evaluation:
(loop for x = (read-char) until (funny-char-p x) do (process-char x))
** Value on first time computed differently than on subsequent iterations:
(loop for x = #\( then (read-char) ...)
;; First time, x is set to #\(; subsequent times it calls read-char.
DESTRUCTURING and TYPE DECLARATIONS
A list may be used whereever a variable is called for, and the value for
that "variable" will be "destructured" (see CLtL, p146). Variables may
be followed by optional type specifiers, which are limited to FIXNUM
INTEGER, NUMBER, NOTYPE, T and the floating-point types. These are
considered advanced topics; see the Loop reference manual for details.
!
LOOP Iteration Macro CRIB SHEET
Below is an abbreviated list of the more commonly used LOOP syntax tokens
(sometimes called "Loop Keywords"); a BNF description of the legal format
is given, along with an example for each one.
Iteration Control
------------------------------------------------------------------------------
FOR <var> [{FROM | DOWNFROM | UPFROM} <expr1>]
[{TO | DOWNTO | UPTO | BELOW | ABOVE} <expr2]
[BY <expr3>]
(loop for i integer from 0 to 10 by 2
do (format t "~A" i)) ==> 0 2 4 6 8 10
(loop for i downfrom 6 above 0
do (format t "~A" i)) ==> 6 5 4 3 2 1
FOR <var> IN <expr1> [BY <step-function>]
(loop for i in '(1 2 3) sum i) ==> 6
FOR <var> ON <expr1> [BY <step-function>]
(loop for (i) on '(1 2 3) sum i) ==> 6
FOR <var> FIRST <expr1> THEN <expr2>
FOR <var> = <expr1> [THEN <expr2>]
(loop for i first 2 then (* i i)
until (> i 500)
collect i) ==> (2 4 16 256)
(loop for i = (read-char)
until (eql i #\newline)
collect i) ==> (#\a #\b ...)
FOR <var> BEING EACH ELEMENT OF <sequence>
FOR <var> BEING THE ELEMENTS OF <sequence>
(loop for dollars being each element of #(2 9 4 6)
sum dollars) ==> 21
(loop for char being the elements of (the simple-string "abcd")
collect char) ==> (#\a #\b #\c #\d)
AS is a synonym for FOR
REPEAT
(loop repeat 3 (print "What I say three times it true"))
==> "What I say three times it true"
"What I say three times it true"
"What I say three times it true"
End-Test Control
------------------------------------------------------------------------------
THEREIS <predicate>
(loop for i upfrom 0 thereis (and (> i 10) i)) ==> 11
ALWAYS and NEVER are similar to THEREIS:
(loop for i from 0 to 10 by 3 always (< i 10)) ==> T
(loop for i from 0 to 9 by 3 always (< i 9)) ==> NIL
(loop for i from 0 to 10 never (> i 11)) ==> T
LOOP-FINISH
(loop for i from 1 to 10
do (format t "~A " i)
(loop-finish)) ==> 1
WHILE <predicate>
UNTIL <predicate>
(loop while (hungry-p) do (eat))
(loop until (not (hungry-p)) do (eat))
Value Accumulation
------------------------------------------------------------------------------
COLLECT <item> [INTO <var>]
(loop for i from 1 to 5 collect i) ==> (1 2 3 4 5)
APPEND <list> [INTO <var>]
(loop for i in '((a) (b) ((c) d)) append i) ==> (A B (C) D)
NCONC is similar to append, but uses NCONC function rather than APPEND.
SUM <number> [INTO <var>]
(loop for i in '(1 2 3 4 5)
sum i into lots
finally (return (list lots lots))) ==> (15 15)
COUNT <form> [INTO <var>]
(loop for i in '(a 2 nil c t "x") count i) ==> 5
;; Remember -- nil is not counted
MAXIMIZE <expr> [INTO <var>]
MINIMIZE <expr> [INTO <var>]
(loop for i in '(2 1 5 3 4)
maximize i into moby
finally (cogitate-upon moby)) ==> NIL
;; No automatic return value, bug 'cogitate-upon'
;; is called with value 5 in the finally clause.
Binding Variables
------------------------------------------------------------------------------
WITH <var> [= <initial-value>]
(loop with x = 10
for i from 1 to 3
do (format t "~A " x)) ==> 10 10 10
Conditional Execution
------------------------------------------------------------------------------
<c-clause> ::=
{ DO <form>+ | {COLLECT <item> | APPEND <list> | SUM <number> | etc.} }
IF <predicate> <c-clause> [ELSE <c-clause>]
WHEN <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10
if (< i 5)
do (format t "~A " i)
else
do (format t "*")) ==> 1 2 3 4 *****
UNLESS <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10 unless (< i 5) count i) ==> 6
Unconditional Execution
------------------------------------------------------------------------------
DO <form>+
(loop for i from 16 to 18
do (format t "~D " i)
(format t "~X " i)) ==> 16 10 17 11 18 12
Initial and Final Evaluation
------------------------------------------------------------------------------
INITIALLY <form>
(loop initially (format t "++ ")
for i from 1 to 5
do (format t "~A " i)) ==> ++ 1 2 3 4 5
FINALLY <form>
(loop finally (format t "++")
for i from 1 to 5
do (format t "~A " i)) ==> 1 2 3 4 5 ++
!
LOOP EXAMPLES
Since the LOOP facility is implemented as an ordinary Common Lisp macro,
it is often instructive to call MACROEXPAND-1 on a LOOP expression to
see how it gets translated into "vanilla" code. In the example below,
the goal of the loop is to find the tail of '*temporary-code*' just before
the cell that contains a suitable code-vector; this cell will subsequently
be "spliced" out of the *temporary-code* list.
(macroexpand-1 '(loop initially (setq temp-cell *temporary-code*)
while (not (null (rest temp-cell)))
thereis (<=& len (code-length (second temp-cell)))
do (pop temp-cell)))
==>
(let ((#:it1 nil))
(block nil
(tagbody
(setq temp-cell *temporary-code*)
loop::begin-loop
(unless (not (null (rest temp-cell)))
(loop-finish))
(when (setq #:it1 (<=& len (code-length (second temp-cell))))
(return #:it1))
(pop temp-cell)
(go loop::begin-loop)
loop::end-loop)))
Here is another realistic, complex example taken from one version of the
Lucid debugging module. Notice how the essential control parts of the loop
structure are highlighted by being at "top level":
-- there are few (if any) hidden exits from the loop.
-- Numerical "stepping" is invoked by a very succinct, stylized syntax
reminiscent of mathematical notation, rather than the cumbersome,
and distributed, code parts for Common Lisp DO.
-- "stepping" that doesn't fit into the provided formats can be
modeled by a three-line sequence of WITH/DO/WHILE clauses.
(loop for i upfrom (- frames-to-skip) ;'i' < 0 while skipping; and
below (or limit infinity) ; maybe there's no limit?
with fp = first-fp ;'fp' will chain through
do (setq fp (next-valid-fp ; the sequence of valid
fp ; stack frame pointers.
stack-bottom
report-problems))
while fp ;End of stack? if so, exit now
when (and table-length ;Make sure frame fits
(>= i table-length))
do (format *error-output* ;foo
"Error collecting stack frames")
(loop-finish)
when (and (>= i 0) ;Not skipping
frame-environment) ;Want frame recorded?
do (setf (stack-frame-fp i frame-environment)
fp)
finally (return ;Return # of non-skipped frames
;;I points to the first unused slot in all exit cases,
;;so I is the number of frames stored (or counted)
(max i 0)) ;But never negative
)
∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:41:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 22 Jul 87 10:36:19-EDT
Date: Wed, 22 Jul 1987 10:36 EDT
Message-ID: <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: Iteration proposals
I have a few comments on Loop and the other iteration proposals, but I
assume that this is not the proper forum for detailed discussions,
especially of a preliminary nature. Is the iteration subcommittee now
active, with an internal communication channel for this stuff?
-- Scott
∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 09:44:42 PDT
Received: by labrea.stanford.edu; Thu, 23 Jul 87 09:40:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01235; Wed, 22 Jul 87 19:49:39 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03169; Wed, 22 Jul 87 19:49:57 PDT
Date: Wed, 22 Jul 87 19:49:57 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707230249.AA03169@bhopal.edsel.uucp>
To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!x3j13%sail@labrea.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 22 Jul 1987 10:36 EDT <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Subject: Iteration proposals
At the Palo Alto X3J13 meeting in mid-March, Chris Perdue offered to set up a
mail redistribution list for the iteration sub-committee, at Sun. After a
few false starts, I think some mail successfully was forwarded through
"sun!clam!loop-groop"; but about mid-May, several of the committee members
fell into the proverbial black hole of "other committments", and there
haven't been any mailings through that channel since then.
None of the iteration committe members were present at the Boston meeting
except myself (and you weren't there either?); so we didn't even have our
face-to-face meeting, as planned. For the time being, I guess individual
contact is still the only active channel; the addresses, as last I knew
them, were:
edsel!jonl@labrea.stanford.edu (Jon L White)
DLW@SCRC.Symbolics.COM (Dan Weinreb)
cperdue@sun.COM (Chris Perdue)
Pavel.pa@Xerox.COM (Pavel Curtis)
GSB@mc.lcs.mit.edu (Glenn Burke)
-- JonL --
∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
Received: from [128.62.1.126] by SAIL.STANFORD.EDU with TCP; 14 Aug 87 08:00:52 PDT
Date: Fri, 14 Aug 87 09:42 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Windows Subcommittee
To: X3j13@sail.stanford.edu
cc: Loeffler@MCC.COM
Message-ID: <870814094226.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
What is the current status of the windows committee? I have two people
here at MCC that would like to participate.
-- David D. Loeffler
∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 04:24:36 PDT
Date: 14 Sep 1987 19:53-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: report on ISO NWI and SC22 meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]14-Sep-87 19:53:33.MATHIS>
At our meeting in Boston in July, the proposed New Work Item for an
international standard for Lisp was discussed. After a mail ballot of the
membership, it was decided (and subsequently endorsed by X3, the parent
committee of X3J13 and the organization responsible for the final US vote on
this issue) to forward the following comments with our ballot:
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Other countries have also submitted comments -- France offered a Convenor,
Japan thought there should be more emphasis on Common Lisp, and the United
Kingdom emphasized the need for a single standard.
ISO/IEC JTC1/SC22 (the SubCommittee on Languages of Joint Technical Committee
1 of the International Organization for Standardization and the International
Electrotechnical Commission) decided to form Working Group 16 on Lisp.
Christian Queinnic was named Convenor and Richard Gabriel and William Klinger
were named as project editors.
At that same meeting there was considerable discussion about the handling of
large character sets in programming languages. While this issue is frequently
thought of in terms of handling Japanese and Chinese, it is also important for
European languages other than English and for modern text manipulation
systems.
The first meeting of WG 16 will be held February 24 and 25, 1988, in Paris,
France. There will be an International Workshop on Lisp Evolution and
Standardization on February 22 and 23, also in Paris. Participation in the
Workshop is separate from participation in the ISO/IEC Working Group.
∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 87 09:28:34 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 15 Sep 87 10:27:15 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 15 Sep 87 10:27:41 mdt
Return-Path: <dcm@hpfcdcm>
Message-Id: <8709151627.AA15748@hpfcdcm.HP.COM>
To: x3j13@sail.stanford.edu
Cc: mathix@ada20.isi.edu
Subject: October X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Tue, 15 Sep 87 10:27:37 MST
Sender: dcm%hpfclp@hplabs.HP.COM
X3J13 Meeting
10/20/87 - 10/21/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday,
October 19-21 at the University Park Holiday Inn in Fort Collins,
Colorado. Monday has been set aside for committee meetings, followed
by the main meeting on Tuesday and Wednesday. October is the perfect
time to see fall (and sometimes winter) in Colorado. Rocky Mountain
National Park is approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated
discount airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your
room, rental car, or airport limousine reservations through Lifeco at
the same time. Payment must be made by credit card. Tickets will be
mailed via registered mail. Late reservations can be express mailed
at additional cost.
A block of rooms is available at the University Park Holiday Inn at
$46.50 plus tax per night. If you don't make reservations through
Lifeco Travel, please make your own reservations by calling
(303)482-2626 and asking to reserve a room in the "HP X3J13" block.
Reservations will be held until 6 PM unless guaranteed by a major
credit card. Non-smoking rooms are available. Check-in and check-out
times are 1 PM. The block of rooms will be dropped on 10/2/87, but
you should still be able to obtain the discounted room rate on
available rooms if you specify you are attending the the "HP X3J13"
conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday.
I expect these arrangements will run $50 or less per person which I
will collect at the meeting. I should be able to update this value in
a few weeks. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner
Tuesday evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate
cafe offering some the best and most unusual food in Northern
Colorado. It is a very small cafe which can only accommodate 60 total
patrons, but they are willing to put together a special banquet for
us. To handle a group this large in a short period of time they would
like to limit the menu to 4 items. The list of possible entrees
includes: Cajun roast duckling with spice peach gravy, chicken boursin
(double breast of chicken stuffed with herbed cream cheese dressing
and mushroom voloute' sauce), shrimp diane (sauteed jumbo shrimp in a
garlic cajun sauce), sirloin tips with mushrooms and onions, poached
salmon with a special sauce, or boned leg of lamb stuffed with spinach
and served with a dijon sauce. A vegetarian entree will also be
available. Entrees would be about 15 dollars, including soup or
salad. Appetizers, dessert, and beverage would be ala carte.
Cuisine, Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in
advance so they could make the necessary preparations. Note if you
are interested on the registration form and mark your first and second
choice entrees. Please note any dietary restrictions if this
selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to
I-25 and go north on I-25 towards Cheyenne, Wyoming. Take the first
Fort Collins exit, #265, turn left and drive 5 miles to the College
Avenue intersection. Turn right and drive 3 miles to the Prospect
Road intersection. Turn left and the Holiday Inn is just across the
railroad tracks on the south side of the road. It shouldn't be hard
to see since it is 8 stories tall in an area with very few building
over 2 stories.
Two limousine services provide shuttle service from Stapleton directly
to the Holiday Inn. Fort Collins Express (303-482-0505) leaves
Stapleton on the hour while the Front Range Airporter (303-221-5466)
leaves Stapleton on the half hour. Both are located in the baggage
claim area. The charge is $12 each way on the Express and $13 on the
Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by October 5 via
electronic mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions
__________________________________________________________________________
X3J13 OCTOBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 10/20 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 11:45:10 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 16 Sep 87 12:43:25 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 16 Sep 87 12:43:23 mdt
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 16 Sep 87 12:43:19 MST
Message-Id: <1297.558816199@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Bob Mathis requested that I delay the meeting a month so the subcommittees
will have more time to prepare their reports. I have rescheduled the
meeting a month later, November 16-18, which seemed to be the most
desirable dates in November. Other than the date changes there are no
other changes in the arrangements.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 or less per person which I will
collect at the meeting. I should be able to update this value in a few
weeks. Please note any dietary restrictions so I can make the necessary
arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa25268; 24 Sep 87 6:13 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay09298; 24 Sep 87 6:00 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA23717; Thu, 24 Sep 87 17:39:32 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA00464; Thu, 24 Sep 87 17:14:20 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:47 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA16011; Thu, 24 Sep 87 14:50:53 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA01964; Thu, 24 Sep 87 14:37:43 JST
Date: Thu, 24 Sep 87 14:37:43 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709240537.AA01964@kurims.kurims.kyoto-u.junet>
To: x3j13@SAIL.STANFORD.EDU
Subject: Japanese Activities toward Lisp Standardization
Japanese Activities toward Lisp Standardization
The demand for Lisp standardization has been growing rapidly in Japanese
computer industries and academic organizations. AIST (Agency of Industrial
Science and Technology), which is responsible for Japan Industrial Standards
(JIS in short), has initiated its activity toward JIS Lisp standardization.
In April 1986, in response to the request from AIST, a working group for Lisp
standardization was formed at JEIDA (Japan Electronic Industry Development
Association). After one year's preliminary discussions, the following
committee "JEIDA Committee for Lisp Standardization" was formed and its
active efforts have begun in June 1987. The aim of this committee is to
develop a Lisp language specification suitable for JIS standard in cooperation
with ISO and the organizations for Lisp standardization in other countries.
JEIDA Committee for Lisp Standardization
----------------------------------------
Chairman:
Takayasu Ito (Tohoku University)
Secretaries:
Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.)
Fumio Motoyoshi (ETL: Electrotechnical Laboratory)
Taiichi Yuasa (Kyoto University)
Members from Major Computer Companies:
Fujitsu Ltd.
Hitachi Ltd.
IBM Japan Ltd.
Mitsubishi Electric Corp.
NEC Corp.
Oki Electric Industry Co. Ltd.
Toshiba Corp.
Observers:
Masayuki Ida (Aoyama Gakuin University)
Tetsuo Ida (The Institute of Physical and Chemical Research)
Ryo Kamito (AIST)
Masakazu Nakanishi (Keio University)
Takehisa Nireki (JEIDA)
Kentaro Shimizu (University of Tokyo)
Technical issues for Lisp standardization will be discussed by the subsidiary
working group "JEIDA Technical Working Group for Lisp Standardization", or
TG/A in short. This group started technical discussions soon after it was
formed in August 1987. It has been agreed that Common Lisp is a good starting
point for technical discussions. But various technical deficiencies of Common
Lisp have been already pointed out at TG/A. The role of TG/A is to clear up
major technical issues for Lisp standardization, continuing detailed technical
examinations on Common Lisp and other Lisp dialects.
JEIDA Technical Working Group for Lisp Standardization
------------------------------------------------------
Chairman:
Taiichi Yuasa (Research Institute for Mathematical Sciences,
Kyoto University)
Members:
Takashi Chikayama (ICOT)
Etsuya Shibayama (Dept. of Information Science,
Tokyo Institute of Technology)
Kentaro Shimizu (Dept. of Information Science, University of Tokyo)
Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.)
Kyoji Umemura (NTT Software Lab., NTT)
Advisors:
Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.)
Michiaki Yasumura (Central Research Lab., Hitachi Ltd.)
Anyone interested in Japanese activities for Lisp standardization should
contact:
Professor Takayasu Ito
Department of Information Engineering
School of Engineering
Tohoku University
Sendai 980, Japan
Junet: chairlsp@nttlab.ntt.junet
or
Dr. Taiichi Yuasa
Research Institute for Mathematical Sciences
Kyoto University
Kyoto 606, Japan
Junet: yuasa@kurims.kurims.kyoto-u.junet
∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Oct 87 16:36:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae00813; 20 Oct 87 18:19 EDT
Received: from csl.ti.com by RELAY.CS.NET id ah15609; 20 Oct 87 18:17 EDT
Received: from Jenner by tilde id AA13643; Tue, 20 Oct 87 16:18:06 CDT
Message-Id: <2770752076-11152612@Jenner>
Date: Tue, 20 Oct 87 16:21:16 CDT
From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
To: dcm%hpfclp@hplabs.hp.com
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: November X3J13 meeting
In-Reply-To: Msg of Wed, 16 Sep 87 15:39:35 cdt from tilde::@relay.cs.net, @sail.stanford.edu:dcm%hpfclp@hplabs.hp.com
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: Patrick Dussud
Institution: Texas Instruments Austin.
Street Address: 12501 research Blvd
City, State, Zip: Austin TX 78759
Phone: (512) 250-7483
Network Address: Dussud%jenner%ti-csl.csnet
Dinner 11/17 (y/n): N__________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 08:39:11 PDT
Date: 22 Oct 1987 11:36-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: November Meeting
From: ROSENKING@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]22-Oct-87 11:36:22.ROSENKING>
To all those planning to attend the November meeting:
If anyone is interested in indulging in some pre-meeting skiing, on
Saturday and Sunday (Nov. 14-15) at Breckenridge or Keystone mountains
in Colorado, drop me some mail. I am gathering accomodation and prime
ski condtion information at this time and I plan on making reservations
shortly.
All are welcome ! Lisp experience is a plus, though not for skiing ?!
- Jeff Rosenking
∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 05:21:58 PST
Date: 26 Oct 1987 05:21-PST
Sender: MATHIS@C.ISI.EDU
Subject: next meeting
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 05:21:15.MATHIS>
I hope you are all making your reservations for the next meeting,
Nov 16-18, in Colorado.
Messages about this were sent out to this list some time ago and
in the mail just recently.
Monday afternoon is for subcommittee meetings -- people who are
planning such should either respond to me directly or announce
them on this list.
Tuesday we will start about 9am.
Wednesday I would like to leave Denver about 7pm. That means the
meeting can run until 5pm. I expect that people will be staying
for the full afternoon. If a four o'clock ending time would
help, let me know so others can plan on it too.
As to the agenda -- I expect some discussion about windows on
Tuesday; some discussion about the Lisp1/Lisp2 issue; some
discussion about planning for the international work; more on
CLOS; and an extensive report from the clean-up committee (they
have been busy, but won't have their report mailed around in
advance). There are also other committees that will be
reporting.
If you have any suggestions for agenda organization, please let
me know. I will try to put out a more complete version by the
end of the week (if you get back to me).
Thanks, Bob
∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:33:31 PST
Date: 26 Oct 1987 12:32-PST
Sender: MATHIS@C.ISI.EDU
Subject: Wednesday afternoon agenda
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 12:32:47.MATHIS>
I have already gotten an indication from a few people that they
have to leave around 2pm or 3pm Wednesday afternoon. That's
fine. However, it might make sense to have the last item on the
Wednesday agenda be something that might be considered less
central to the overall work. Any suggestions?
Thanks, Bob
∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 12:12:47 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 12:08:43-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Thu, 29 Oct 87 12:10:07 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Thu, 29 Oct 87 12:58:33 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Thu, 29 Oct 87 12:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Thu, 29 Oct 87 12:57:30 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Thu, 29 Oct 87 12:57:27 MST
Message-Id: <5124.562535847@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Last call for reservations and registrations. Please send me a
registration form in addition to making your reservations. I need to give
a tentative head count to the the hotel and the restaurant next Monday,
November 2, with final counts due the following Monday, November 9. So far
I've heard from the following people:
Kathy Chapman Digital Equipment Corporation
Walter van Roggen Digital Equipment Corporation
Dan Pierson Encore Computer Corporation
Sandra Loosemore Evans & Sutherland Computer Corp.
Steve Haflich Franz Inc.
Kevin Layer Franz Inc.
James Kempf Hewlett Packard Company
Dave Matthews Hewlett Packard Company
George Hadden Honeywell
Aaron Larson Honeywell
Thom Linden IBM
Mary Van Deusen IBM
Dick Gabriel Lucid, Inc.
JonL White Lucid, Inc.
Linda DeMichiel Lucid, Inc.
Christopher Dabrowski National Bureau of Standards
Chris Perdue Sun Microsystems
Sonya Keene Symbolics, Inc.
David Moon Symbolics, Inc.
David Bartley Texas Instruments
Patrick Dussud Texas Instruments
Daniel Bobrow Xerox Corporation
Pavel Curtis Xerox Corporation
Gregor Kiczales Xerox Corporation
Larry Masinter Xerox Corporation
The dinner selections thus far seem to favor duck, shrimp, chicken, and
lamb using a simple first choice heuristic.
First choice Second Choice
Shrimp XXXX XXXX
Lamb XXXX XXXXX
Sirloin XX XXXX
Duck XXXXX XX
Salmon XX XXXXX
Chicken XXX X
Veg. X
A few ski resorts have already opened, Jeff Rosenking is looking for other
skiers to join him on a trip the weekend before the meeting. Your ski
reservations, including lift tickets, can also be made through Lifeco
travel when you make your travel reservations.
There are some small board rooms available at the hotel if you would like
to use them Monday for committee meetings. Please let me know what times
you would like to reserve one so I can have one set aside for you.
By the way, I seem to have typoed my phone number in the last mailing. The
correct phone number is (303)229-2201.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 per person which I will collect at
the meeting. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)229-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂11-Nov-87 1800 X3J13-mailer Final reservations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:13:02 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 17:08:57-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:12:18 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:58:16 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:57:43 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ADA20.ISI.EDU
Subject: Final reservations
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 11 Nov 87 17:57:40 MST
Message-Id: <1830.563677060@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
I've scheduled two conference rooms for Monday afternoon for
subcommittee meetings - one for the cleanup committee and one for
the character committee. They will be available all afternoon.
This is the latest list of registrants and dinner guests that I
have. If you aren't listed, such as Bob Mathis, and plan to
attend, please give me a call.
I've eliminated the chicken and salmon as a result of low demand
and added a new dinner choice column to the list of registrants.
Please call me if you have ????? for your dinner selection as you
will need to choose something else.
If you have any questions or need additional help call me and
leave a detailed message if I'm not available. I'll try to get
back to you ASAP.
Dave Matthews
303-229-2201
Peter Coffee Aerospace Corporation -
Jim O'Dell Alliant Computer sirloin
Kathy Chapman Digital Equipment Corporation veg
Walter van Roggen Digital Equipment Corporation duck
Dan Pierson Encore Computer Corporation duck
Sandra Loosemore Evans & Sutherland Computer Corp. shrimp
Steve Haflich Franz Inc. ??????
Kevin Layer Franz Inc. sirloin
Richard Greenblat GigaMOS Systems, Inc. sirloin
Jeff Rosenking Grumman Corporation shrimp
Paul Beiser Hewlett Packard Company shrimp
James Kempf Hewlett Packard Company duck
Dave Matthews Hewlett Packard Company lamb
George Hadden Honeywell shrimp
Aaron Larson Honeywell shrimp
Thom Linden IBM shrimp
Mary Van Deusen IBM duck
Greg Nuyens ILOG S.A. duck
Jerome Chailloux INRIA/ILOG duck
Mary Boelk Johnson Controls, Inc. shrimp
Dick Gabriel Lucid, Inc. sirloin
JonL White Lucid, Inc. lamb
Jan Zubkoff Lucid, Inc. duck
Linda DeMichiel Lucid, Inc. lamb
David Loeffler MCC sirloin
Christopher Dabrowski National Bureau of Standards -
Eric Schoen Schlumberger Palo Alto Research -
Chris Perdue Sun Microsystems duck
Sonya Keene Symbolics, Inc. sirloin
Bob Kerns Symbolics, Inc. ??????
David Moon Symbolics, Inc. -
Kent Pitman Symbolics, Inc. duck
Will Clinger Tektronix Laboratories -
David Bartley Texas Instruments lamb
Patrick Dussud Texas Instruments -
Ellen Waldrum Texas Instruments shrimp
Guy Steele Thinking Machines Corporation shrimp
Thomas Turba Unisys Corp. shrimp
Julian Padget University of Bath duck
Jeff Dalton University of Edinburgh sirloin
Daniel Bobrow Xerox Corporation lamb
Pavel Curtis Xerox Corporation lamb
Andy Daniels Xerox Corporation lamb
Gregor Kiczales Xerox Corporation duck
Larry Masinter Xerox Corporation shrimp
∂12-Nov-87 1335 X3J13-mailer next meeting
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:34:57 PST
Date: 12 Nov 1987 16:18-EST
Sender: MATHIS@A.ISI.EDU
Subject: next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]12-Nov-87 16:18:49.MATHIS>
I've talked to Dave Matthews. If there are any other remaining
reservations, please let him know.
The agenda will be committee reports and regular business on
Tuesday morning. Tuesday afternoon I think will be best spent on
more informal, but more in depth, discussions of the work of the
CLOS and clean-up committees. Wednesday will contain a
continuation of these discussions and also the formulation of a
ballot on clean-up issues (since they haven't been distributed in
advance we can't finalize the vote at the meeting, on the other
hand we may not be to the stage of having a formal mail ballot
either).
We also have to discuss our plans for a standard for Common Lisp
and our plans for the ISO work. There will also be reports from
the editorial, windows, characters, and other subcommittees.
The agenda is not full of a lot of little topics, but is oriented
toward reaching some general understanding of the issues
involved.
-- Bob
∂29-Nov-87 1424 X3J13-mailer subcommittees
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 14:24:00 PST
Date: 29 Nov 1987 17:22-EST
Sender: MATHIS@A.ISI.EDU
Subject: subcommittees
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
here is my version of how the subcommittee evolved at the Ft. Collins
meeting. PLEASE send me any additions or other corrections.
If you have an electronic mailing list, please let me know and tell
me how people outside the subcommittee should be involved with that
list (if at all)
X3J13 Subcommittees (as of November 29, 1987
(Mathis, Steele, and Gabriel try to follow all)
Editorial:
Kathy Chapman, chair
Ron Ohlander
Mary Boelk
Dick Gabriel
Kent Pitman
Walter van Roggen
Skona Brittain
Character Subcommittee <cl-natural-languages
Thom Linden, chair (IBM Research)
Larry Masinter (XEROX Research)
Carl Hoffman (International Lisp Associates)
Bob Kerns (Symbolics)
Duncan Missimer (Hewlett-Packard)
Dave Matthews (Hewlett-Packard)
Mike Beckerle (Gold Hill)
Kevin Layer (Franz)
ISO/IEC JTC1/SC22/WG 16 Delegation:
Dick Gabriel, chair
Guy Steele
Bob Mathis
Patrick Dussud
Thom Linden
Larry Masinter
Will Clinger
Bill Scherlis
Kent Pitman
John McCarthy
Iteration
Jon L. White, chair
Pavel Curtis
Chris Purdue
Dan Weinreb
Errors and Conditions
Kent Pitman, chair
Andy Daniels
Validation and Conformance
--, chair
David Slater
Mike Beckerle
Chris Dambroski
Compiler Specification
Steve Haflich, chair
David Bartley
Mike Beckerle
Rob McLaughlin
Walter van Roggen
CLOS
Danny Bobrow, chair
David Moon
Dick Gabriel
Gregor Kiczales
Linda DeMichiel
Sonya Keene
Patrick Dussud
Jim Kempf
Lisp1/Lisp2
Dick Gabriel
Will Clinger
Kent Pitman
Mark Wegman
Richard Greenblat
Dan Weinreb
Macros
Mark Wegman
Julian Padget
Steve Haflich
Kent Pitman
Graphics and Windows
Erik Schoen, chair
George Haden
Ellen Waldrum
Types & Declarations
Bill Scherlis
Clean-up
Larry Masinter
Guy Steele
Kent Pitman
JonL White
Scott Fahlman
David Moon
Ellen Waldrum
Meeting Planning
Jan Zubkoff
∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:44:53 PST
Received: by labrea.stanford.edu; Wed, 2 Dec 87 15:41:10 PST
Received: from sunvalleymall.lucid.com by edsel id AA11888g; Wed, 2 Dec 87 15:35:55 PST
Received: by sunvalleymall id AA08895g; Wed, 2 Dec 87 15:35:59 PST
Date: Wed, 2 Dec 87 15:35:59 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712022335.AA08895@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Subject: 11-87 minutes
Plans for March meeting to follow.
X3J13/87-038
Minutes
Ft. Collins, CO
11/17/87 - 11/18/87
Item 1: Call to Order, Bob Mathis
9:00 am - Tuesday, November 17, 1987. Ft. Collins meeting called to order.
Introductory remarks. Attendance list send around. Introduction of
attendees.
Item 4: Report on ISO Ballot (Doc: 87-031), Bob Mathis
Letter from Bob Mathis to Catherine Kachurick. Letter from Thomas Turba to
Bob Mathis. Letter from Catherine Kachurick to X3. Preliminary Draft of
ISO/IEC JTC 1 Information Technology Secretariat: USA (ANSI). Summary of
Voting Document. Proposed comments from US on the name for the resulting
ISO standard on LISP. Draft UK Position on LISP.
Item 2: Approval of Agenda, Bob Mathis
Proposed agenda (X3J13/87-037) approved with minor changes. No windows and
a shorter CLOS discussion.
Item 5: Other administrative matters, Bob Mathis
New document register is available. List of subcommittees (please send
Mathis changes of members and send electronic mailing address). X3 bills
have been sent out. Make checks for this meeting payable to Hewlett Packard
and give to Dave Matthews during break. Dinner will be at 6:30pm.
Item 8: Characters, Thom Linden Committee name and scope. Name change
Natural Language Committee to Character Committee. JEIDA acknowledgement
and interaction network. IBM proposal. Thom will have a detailed proposal
at the March meeting. Committee will discuss one topic at a time. Bob
Mathis will forward ISO character notes to Thom Linden.
Item 9: Iteration, JonL White
Work promised on MIT LOOP at Cambridge meeting has just begun. Discussion
on whether standard is needed for portable loops. Discussion on why loop
and do standards may be necessary for new programmers.
Item 10: Lisp1/Lisp2, Common Lisp and Scheme, Will Clinger
Discussion on denotational semantics. Should we dissolve the Lisp1/Lisp2
committee? Should we broaden the committee to look at semantics of the
entire language? We need to take a vote.
11:30am - Morning Break
Item 12: Reports from other subcommittees
Errors, Kent Pitman
No new revisions. Will send mail with questions posed since last meeting.
Will have proposal for approval at next meeting.
12:00 - Lunch
Item 11: Editorial, Kathy Chapman
Discussed whether spec should be CLtL with changes or start from scratch.
Presented idea of 2 manuals, one a formal spec and one a rationale manual.
We need to decide what the deadline for the manual is.
2:30 pm - Break
Item 12: Reports from other subcommittees
Macros, Julian Padget
Brief overview. Please send examples of hairy macros to Julian Padget. A
brief summary will be available at next meeting.
Item 12: Reports from other subcommittees
CLOS, Gregor Kiczales
Committee has filled in chapters 1 and 2. Chapter 3 will be decided in
December at a Meta Objects meeting in Boston. Changes include: loosened
lambda-list congruence rules, instance creation and initialization,
simplified with-slots, handling some exception conditions, and lexical
generic functions. Next revision will be available in February 1988.
Please send comments via net-mail by end of February so changes can be made
by the March meeting.
Item 12: Reports from other subcommittees
Validation, Bob Mathis
Rich Berman has left ISI. This leaves the validation committee unmanned.
Item 12: Reports from other subcommittees
Type and Declaration, Bob Mathis
Bill Scherlis was to report. Nothing has been reported.
4:15pm - Break
4:25pm - Bob Mathis proposed the agenda for Wednesday's meeting be 9:00 -
10:30 Cleanup Committee, wrapping up by lunch and have committee meetings
after lunch.
Item 14: Extended Discussion on CLOS and Clean-up, Larry Mascinter
General remarks and review issue status. Intent is writing for editor the
go-ahead on issues. Ran quickly through issues.
Item 15: Recess, 4:55pm
Item 16: Call to Order, November 18, 8:59am, Bob Mathis
Item 17: Further discussions on cleanup and drafting, Larry Mascinter
The following people contributed issues and discussions but are not on the
clean-up committee. We thank them for their participation.
Dan Carnese Schlumberger
Will Clinger Tektronics
Pavel Curtis Xerox
Steve Haflich Franz
Dieter Kolb Siemans
Sandra Loosemore E&S/Utah
Rob McLaughlin CMU
Jeff Peck SUN
Jonathan Rees MIT
Dave Touretzky CMU
Discussed "need volunteer" issues. Bob Mathis will mail a ballot on closed
topics from clean-up committee. JonL White proposed we bring forward old
issues and reject or adopt them. Larry Mascinter will provide a list.
AREF-1D no comments or objections
GET-SETF-METHOD-ENVIRONMENT no comments or objections
KEYWORD-ARGUMENT-NAME-PACKAGE no comments or objections
PATHNAME-STREAM some comments no objections
DO-SYMBOLS Jonl White suggested DO-PRESENT-SYMBOLS
and will send mail to Larry Masinter.
DECLARE-MACROS Goldhill objected on grounds of incompatible
changes. A long discussion ensued.
10:38am - Break
Item 17: Further discussions on cleanup and drafting, continued.
PATHNAME-SUBDIRECTORY-LIST
Item 22, 24: Planning Relative to Other Technical Issues,
Review Action Item Assignments, Bob Mathis
ISO letter. Committee chairman, people on committees, net names. A motion
was made to thank Lucid, Goldhill and Hewlet Packard. The motion was
approved and Bob Mathis will send thank you letters.
Item 23: Future Meetings, Bob Mathis
Discussion of length and format of future meetings. It was voted that we
would have a 5 day meeting in March 1988 and a tentative date was set for
March 21 through March 25. The first 2 days will be set aside for
subcommittee meetings, the next 2 days will be used for the meeting, and the
last day will be set aside for subcommittee meetings. A reminder that all
proposals should be in the hands of the committee 2 weeks prior to the
meeting. That means mailing 4 - 5 weeks before the actual meeting.
The following meetings are tentatively scheduled June 13 - 17 on the east
coast, September 26 - 30 central or west coast and January 9 - 13 1989 in
Hawaii.
(NOTE: Although March 21 - 25 was discussed as a possible meeting date,
March 14 - 18 has really been set. )
Item 20: Planning for ISO participation, Bob Mathis
Discussion on who should/could go to ISO in February.
Item 25: Adjournment 12:00, Bob Mathis
Jan Zubkoff
Acting Sectretary
∂14-Dec-87 1055 X3J13-mailer March meeting
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 10:55:42 PST
Received: by labrea.stanford.edu; Mon, 14 Dec 87 10:44:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06718g; Mon, 14 Dec 87 10:19:51 PST
Received: by sunvalleymall id AA10259g; Mon, 14 Dec 87 10:20:42 PST
Date: Mon, 14 Dec 87 10:20:42 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712141820.AA10259@sunvalleymall.lucid.com>
To: labrea!x3j13%sail.stanford.edu@labrea.stanford.edu
Subject: March meeting
X3J13
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Thank you Dave Matthew for letting us use the HP discount!
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-0800.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂11-Jan-88 1056 X3J13-mailer mailings
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:55:54 PST
Received: by labrea.stanford.edu; Mon, 11 Jan 88 10:56:00 PST
Received: from sunvalleymall.lucid.com by edsel id AA19685g; Mon, 11 Jan 88 10:49:25 PST
Received: by sunvalleymall id AA28780g; Mon, 11 Jan 88 10:52:13 PST
Date: Mon, 11 Jan 88 10:52:13 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801111852.AA28780@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Cc: edsel!jlz@labrea.stanford.edu
Subject: mailings
This is a reminder that any subcommittee papers need to be mailed
by Friday 2/5 in order to reack committee members in time.
That's only 3 weeks from Friday folks...
---jan---
∂11-Jan-88 1249 X3J13-mailer mailings
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:49:36 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 11 Jan 88 15:49:30 EST
Received: by kali.think.com; Mon, 11 Jan 88 15:49:26 EST
Date: Mon, 11 Jan 88 15:49:26 EST
From: gls@Think.COM
Message-Id: <8801112049.AA11904@kali.think.com>
To: x3J13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 11 Jan 88 10:52:13 PST <8801111852.AA28780@sunvalleymall.lucid.com>
Subject: mailings
I would like to appeal to all subcommittees to try very hard to submit
material for mailing to X3J13 members as Jan has requested. Failure to
use this mailing-out mechanism slows our progress by a factor of two!
(To see why, consider that a proposal based on feedback from the December
meeting can be voted on in March if mailed out ahead, but cannot be voted
on until June if first presented at the March meeting.)
We stand a very good chance of having a draft ready for public review by
December 1988 or maybe March 1989, *provided* that we make good use of time
by mailing proposals out ahead of meetings. Here is a plausible schedule,
if also an optimistic one:
February: Mail out current CLOS draft.
Mail out current error proposal draft.
Mail out cleanup proposals so far.
Mail out other proposals (character sets? iteration?).
March: Vote on all this stuff. Probably CLOS needs two more
iterations and error proposal needs one more iteration.
Some small fraction of cleanup proposals require iteration.
May: Mail out CLOS draft N-1.
Mail out error proposal draft M.
Mail out more cleanup proposals.
Last chance to mail other proposals without blowing the schedule.
Mail out whatever draft manual the editorial committee has so far.
June: Vote on CLOS draft; probably needs one more round.
Vote on error draft; with any luck this is final or
requires only very minor tweaking.
Vote on more cleanup proposals.
Vote on other proposals. Probably more work needed.
Provide feedback to editorial committee (now and by mail later).
August: Mail out CLOS draft N.
Mail out more cleanup proposals (the last ones???).
Mail out draft standard.
September: Vote on CLOS draft. With any luck this is final. (If we cannot
get a final vote by now, I despair of ever having one.)
Vote on cleanup proposals.
Vote on other proposals.
Provide lots of feedback to editorial committee.
November: Mail out reasonably final draft standard.
December: Vote on draft standard. Either it is ready for public review
or it isn't. (It need not be absolutely perfect, but should
be in good shape.) If it isn't, then another vote in March
is needed.
Such a schedule will demand hard work by the subcommittees, especially the
CLOS, cleanup, and editorial committees. I do know that Larry Masinter has
been working hard on the cleanup proposals, and the CLOS group met in
mid-December. Everyone else should only work so hard. If we do not have
the ambition to try for a schedule like this, then we are looking at a
public review in 1990 or beyond, at our present rate, and a standard
perhaps not until 1992. We need it much sooner than that.
Let's get cracking.
--Guy
∂26-Jan-88 1107 X3J13-mailer voting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:07:26 PST
Date: 26 Jan 1988 14:06-EST
Sender: MATHIS@A.ISI.EDU
Subject: voting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
At the upcoming meeting (March 14-18, including subcommittees)
in Palo Alto, I expect that we may be voting on some things.
After reviewing the attendance records of the last two meetings,
the following members representatives will be eligible
to vote (assuming they have also paid their X3 service fee).
If there are any questions or corrections, please contact me
as soon as possible.
-- Bob
Company Name Cambridge
====================================
Ft. Collins
A.I. Architechs X
Aerospace X
Alliant X
Bath, U. X X
CSC X
DEC X X
Edinburgh, U. X X
Encore X
Evans & Southerland X
Franz X X
Gensym X
Gigamos X X
GMD X
Goldhill X X
Gould X
Grumman X X
Hewlett Packard X X
Honeywell X X
IBM X X
ILOG S.A. X
INRIA X
Internat. Lisp Assoc. X
Johnson Controls X X
Lucid X X
Mathis X X
MCC X X
Micro. Sys. Consults. X
MIT X
Mitre X X
NBS X
Prime X
Red Shark Software X
Schlumberger X
Sun X
Symbolics X X
Tectronix X X
Texas Instruments X X
Thinking Machines X X
Unisys X X
USC-ISI X
Wang X
Xerox X X
∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 15:11:15 PST
Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 15:11:29 PST
Received: from sunvalleymall.lucid.com by edsel id AA13089g; Mon, 1 Feb 88 14:55:21 PST
Received: by sunvalleymall id AA09790g; Mon, 1 Feb 88 14:59:40 PST
Date: Mon, 1 Feb 88 14:59:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802012259.AA09790@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Don't forget mailings
Documents for X3J13 should be mailed this week in order to reach
committee members on time. If you need mailing lables please
contact Bob Mathis.
---jan---
∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:28:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:29:36 PST
Date: 13 Feb 88 17:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup sub-committee
To: X3J13@Sail.stanford.edu
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880213-172936-10523@Xerox>
The cleanup committee has a number of issues for discussion and/or voting at the
next X3J13 meeting. I will be mailing out those issues which are ready for
voting at the next meeting, one at a time.
I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis
will help clarify. My current understanding is that you should be prepared
either to vote for endorsing a proposal or should prepare a written objection.
Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise
to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should
*not* be used for technical discussions, however.
The cleanup issues fall into several categories.
Passed X3J13/Jun87:
Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice
vote) at that meeting.
As these were distributed before, they will not be mailed again except by
individual request, although the issues will appear on the ballot.
Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87:
While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the
most recent version was distributed only in hardcopy at the November 1987
meeting.
Passed X3J13/Nov87:
Distributed only via hardcopy at the November 1987 meeting.
New ballot items for Mar88:
Not previously distributed to X3J13, but ready for voting.
In discussion:
Some of these issues may be distributed via electronic mail to X3J13 prior to
the March meeting for discussion at the meeting, although they will not appear
on a ballot at that time.
∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:45:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:45:59 PST
Date: 14 Feb 88 10:45 PST
From: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-104559-1224@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (CLtL p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Version 4 by Masinter, 23-Nov-87
Problem Description:
The interaction of ADJUST-ARRAY and displaced arrays is insufficiently specified
in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Interaction of adjusting and displacement:
Suppose we are adjusting array A, which is perhaps displaced to B before the
ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered, and the
contents rearranged as appropriate. Additional elements of A are taken from the
:INITIAL-ELEMENT. The use of :INITIAL-CONTENTS causes all old contents to be
discarded.
(2) A is not displaced before, but is displaced to C after. As specified in
CLtL, none of the original contents of A appears in A afterwards; A now contains
the contents of C, without any rearrangement of C.
(3) A is displaced to B before the call, and is displaced to C after the call.
(B and C may be the same.) As in case (2), the contents of B do not appear in A
afterward (unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it defaults
to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate to
maintain the existing old contents; additional elements of A are taken from the
:INITIAL-ELEMENT. However, the use of :INITIAL-CONTENTS causes all old contents
to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z, and
array Y is altered by ADJUST-ARRAY, array X must now refer to the adjusted
contents of Y. This means that an implementation may not collapse the chain to
make X refer to Z directly and forget that the chain of reference passes through
array Y. (Cacheing techniques are of course permitted, as long as they preserve
the semantics specified here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it no
longer has enough elements to satisfy X. This error may be signalled at the
time of the adjustment, but this is not required.
Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent to
specifying :DISPLACED-TO NIL; in either case, the array is not displaced after
the call and case (1) or (4) hold.
Rationale:
This interaction must be clarified. This set of rules was proposed some time
ago, as a result of discussions on the Common Lisp mailing list, and this model
has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here, although they
differ in some detail. For example, Symbolics Common Lisp behaves as indicated
except for case (4); in that case, it never copies the contents of B, and all
elements are taken from the :INITIAL-ELEMENT.
Cost to implementors:
Some existing implementations may have to be changed, but adopting any other
model would be worse. Public-domain code implementing this model is available
from CMU.
Cost to users:
This is a relatively uncommon situation, which is the reason it didn't occur to
the original language designers to specify how it works. Any user code that
cares about this issue probably already follows the proposed model.
Benefits:
Clarification of a situation that is currently not addressed by the standard.
Discussion:
The cleanup committee supports this clarification.
Some consideration was given to adding DISPLACED-ARRAY-P or ARRAY-DISPLACED-TO
and ARRAY-DISPLACED-INDEX-OFFSET which would allow access to information as to
whether an array was or was not displaced. However, these are not part of the
current proposal.
A similar issue arises with ADJUST-ARRAY and fill pointers, and will be the
subject of a separate issue.
∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:49:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:50:04 PST
Date: 14 Feb 88 10:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105004-1227@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of what
happens if an argument to APPEND is a dotted list. The only case explicitly
mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any LISP
object, which becomes the tail end of the constructed list. For example, (append
'(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be
returned.
In the degenerate case where there is no last cons (i.e., the argument is NIL)
in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument is a
non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the
same, since these two might legitimately differ in situations involving dotted
lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number of
implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17,
where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list.
Xerox Common Lisp signals an error on APPEND and implements the proposed
interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those implementations
which don't already implement it. However, implementations which have microcoded
APPEND or NCONC incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only NIL
when SAFETY is 0. In this case, depending on implementation details, requiring
an ATOM check rather than a NULL check may slow things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC can
therefore produce dotted lists, some readers may have (incorrectly) assumed that
APPEND and NCONC can reliably deal in general with dotted lists, something that
doesn't appear to be guaranteed by a strict reading. The proposed extension
would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
Discussion:
The cleanup committee supports this proposal.
∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:57:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:57:51 PST
Date: 14 Feb 88 10:57 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: AREF-1D (Version 7)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105751-1238@Xerox>
This issue passed conditionally at the June 1987 meeting of X3J13. This version,
distributed in hardcopy at the November 1987 meeting, clarified some of the
details of the proposal.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
14-Nov-87, Version 7, by Masinter (update discussion)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY efficiently
in Common Lisp because they take arguments of varying rank. Currently, you have
to make a displaced array to work with temporarily and then throw away the
displaced array when you're done. In many cases, this is bothersome because
there is no a priori reason why they should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional access to
the storage backing up a given array assuming the normal row-major storage
layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when the
elements of array are considered in row-major order. Array may be an array of
any dimensionality. row-major-aref may be used with setf. For reference, the
following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts ..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number of
operators that allow users to exploit that order. ROW-MAJOR-AREF is a useful,
simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by loops that
had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve something
like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use this
primitive internally, it's little more than a matter of changing the name of or
otherwise releasing the existing primitive. In some implementations, it might
involve writing a small amount of code or compiler work to make ROW-MAJOR-AREF
work efficiently.
Benefits:
This gives users efficient access to something to which they already have
inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely to be
used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
This issue was conditionally passed at X3J13/June 1987, pending clarification of
some details. Those clarifications have been made in this version.
∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:03:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:03:31 PST
Date: 14 Feb 88 11:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110331-1248@Xerox>
This issue is new.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT do not
mention a :KEY option, although ASSOC and RASSOC have one.
This is often reported as an inconsistency in Common Lisp.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords for
other -IF and -IF-NOT functions. The function, as with the :KEY argument for
ASSOC and RASSOC, is applied to the CAR of the pair in the association list for
ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/ the
key of the association, and by default the car /is/ the key of the association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one with zero
version.
Rationale:
This is an inconsistency in the language that is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions. Others follow
the book and allow :KEY only for ASSOC.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in their
calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the :TEST and
:TEST-NOT keywords, but allow :KEY. For example, consider the family of MEMBER,
MEMBER-IF, and MEMBER-IF-NOT. Although this introduces additional mechanism, it
does so in a way that probably makes it easier to think about which functions do
what, so it would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an oversight.
The cleanup committee supports this proposal.
∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:08:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:08:44 PST
Date: 14 Feb 88 11:08 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: COLON-NUMBER (Version 1)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110844-1256@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: COLON-NUMBER
References: Parsing of Numbers and Symbols (p339-341, 343-344)
Category: CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Problem Description:
CLtL is unclear about whether a colon followed by a potential number is a
potential number. There are passages which seem to address this issue
unambiguously but fail.
Proposal (COLON-NUMBER:UNDEFINED):
Clarify that syntax involving a leading colon followed by a potential number is
not well-defined. That is, use of notation such as :1, :1/2, and :2↑3 in a
position where an expression appropriate for READ is expected is an error.
Rationale:
This makes the status quo apparent.
Current Practice:
Some implementations, such as Symbolics Lisp, claim the right to interpret this
as an ``is an error'' situation where their upward-compatible extension is to
parse ``:1'' as the number 1 (incidentally, but uninterestingly, expressed in
the KEYWORD package).
Other implementations tokenize ``:1'' as a single token, identify it as a
symbol, and then parse it as :\1 would be parsed.
Cost to implementors:
None. This clarification forces no implementations to change.
Cost to users:
Slight. Some users may have mistakenly believed that this was an aspect of the
language that was guaranteed and may have written programs that exploited that
belief. Such incidences are probably very rare, however. Also, even in the few
cases where such code fortuitously worked, implementations are likely to
continue to support it so such code will probably continue to fortuitously work
in many of those rare situations.
Benefits:
Programmer expectations that any useful behavior can be portably relied upon in
this pathological case should be soundly trounced.
Aesthetics:
Arguably a slight improvement in visual aesthetics. What was already a pretty
marginal syntax is discouraged.
Discussion:
Pitman supports this clarification. He thinks this issue is not a big deal, but
it does crop up often enough to be a nuisance. It would be nice to have everyone
acknowledge a unified position, even if that only meant agreeing to disagree.
∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:12:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:13:23 PST
Date: 14 Feb 88 11:13 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-111323-1266@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Version 4 by Masinter 23-Nov-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say whether
*BREAK-ON-WARNINGS* affects warnings output by the compiler. If this is to be
allowed, it should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these functions
are required to break on warnings if *BREAK-ON-WARNINGS* is true (just as if it
calls WARN).
Note: User interface commands provided by particular vendor implementations
which implicitly call COMPILE or COMPILE-FILE could bind *BREAK-ON-WARNINGS*
back to NIL if they felt it important to not break for some reason relating to
cultural compatibility. This would not interfere with the proposed new semantics
for the functions COMPILE and COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when warnings
occur. If the compiler is permitted to warn (separate ballot item), the effect
of this variable on compiler warnings should be nailed down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism might
have to be edited, but it would not be a major change.
Conversion Cost:
Probably little or no user code would be affected by this change.
Benefits:
This would make the language definition more consistent by making it less
subject to special cases. Portable programs can be assured of consistent
behavior when dealing with the compiler.
Aesthetics:
Most users will probably perceive this change as a simplification because it
will allow the kind of warning that comes from WARN and the kind of warning that
comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather than the
language.
We considered but rejected the notion of a separate
*COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be replaced in
its entirity by a more structured signal/handler structure, making this proposal
moot.
∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:25:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:25:36 PST
Date: 14 Feb 88 11:25 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-112536-1283@Xerox>
An earlier version of this issue was distributed at the November 1987 meeting.
!
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
23-Nov-87, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether the documentation part of DEFVAR,
DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and DEFCONSTANT
special forms is not evaluated. That is, it must be a literal string, not a form
which evaluates to a string.
Examples:
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation string") ; OK
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) GENERIC-DOCUMENTATION-STRING) ;
would be an error
Rationale:
To ensure portability, implementations must agree on whether or not this
position is evaluated. Specifying that the position is unevaluated is the
conservative thing to suggest, and consistent with the (unevaluated)
documentation strings in DEFUN, DEFSTRUCT.
Current Practice:
Some implementations evaluate this position. Others do not.
Cost to implementors:
Implementations that did not already check might usefully add a check in the
macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert that the
DOCUMENTATION, if supplied, was a string. The change is likely trivial.
Cost to users:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed. (We know of no current
uses.)
Benefits:
Code portability would be improved. Some programming environment tools might
assume that documentation strings were determinable without evaluation.
Aesthetics:
Slight improvement; this implies consistent treatment for documentation strings
in all defining forms.
Discussion:
We think this is a good idea.
∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:30:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:31:18 PST
Date: 14 Feb 88 11:30 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113118-1288@Xerox>
This issue has not been distributed before. It is originally from Steele's list.
!
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is not a
compiled function, it is first compiled.". The definition of COMPILE says that
"If name is a non-nil symbol, then the compiled-function is installed as the
global function definition of the symbol...". Several implementations have
taken this to mean that if DISASSEMBLE is passed a symbol which has an
uncompiled function definition, then it has the side-effect of (COMPILE
'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never install the
newly compiled function.
Example:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side effects,
especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics,
Xerox, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is probably not
called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled function
may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:22:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:21:29 PST
Date: 14 Feb 88 11:21 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARE-MACROS (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: no
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880214-112129-1276@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting.
There was some opposition at that time. This version includes a more
extensive description of possible alternative coding practices.
!
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
9-Nov-87, Version 2 by Masinter
5-Feb-88, Version 3 by Pitman
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macro expansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be exponential in the depth of nesting
unless a macro-expansion caching mechanism is added.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accommodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Under this proposal, it would not be "permissible for a macro call to
expand into a declaration and be recognized as such, provided that the
macro call appears where a declaration may legitimately appear." (CLtL
p. 154). Macros could not legitimately expand into declarations; the only
valid declarations would be a list whose CAR is the symbol DECLARE.
It would still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The ability to have a macro form expand into a declaration has been shown
to be useful in some situations. More often, however, the presence of
this feature has been seen to cause problems elsewhere in the language.
Ultimately, its benefits have not outweighed its costs.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Cost to implementors:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Cost to users:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Franz and Gold Hill are notable exceptions to the claim that users may
not want this. Both claim to make a reasonable amount of use of macros
which expand into different SPEED and SAFETY declarations, usually
dependent on a global switch.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY ()
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL
(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Another tactic would be:
Old code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *SPEEDY* NIL))
(DEFMACRO USE-STANDARD-SPEED-AND-SAFETY ()
(IF *SPEEDY*
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
`(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))))
(DEFUN FOO ()
(USE-STANDARD-SPEED-AND-SAFETY)
...)
New code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3))))
(DEFUN FOO ()
(DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*))
...)
Still a third tactic would be to actually shadow DEFUN, LET, etc. with
variants that process macro expansions and then to build code in a
package that used the revised DEFUN, LET, etc. eg,
(DEFUN PARSE-BODY (BODY ENV)
(LET ((DECLS '())
(DOC '()))
(DO () ((NULL (CDR BODY)))
(LET ((EXP (MACROEXPAND (POP BODY) ENV)))
(COND ((AND (STRINGP EXP) BODY)
(UNLESS (NULL DOC)
(WARN "More than one documentation string was seen."))
(PUSH EXP DOC))
((AND (NOT (ATOM EXP)) (EQ (CAR EXP) 'DECLARE))
(PUSH EXP DECLS))
(T
(PUSH EXP BODY)
(RETURN NIL)))))
(VALUES BODY (NREVERSE DECLS) (NREVERSE DOC))))
(DEFMACRO MY:DEFUN (NAME LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(DEFUN ,NAME ,BVL ,@DECLS ,@DOC-STRINGS ,@FORMS)))
(DEFMACRO MY:LET (BINDINGS &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(LET ,BINDINGS ,@FORMS)))
...etc.
LAMBDA cannot be done this way, of course, since it is not a macro (or
even a special form). Support for expanding declarations in a LAMBDA
would have to be provided either by using implementation-specific support
(such as Zetalisp's ``lambda macros'') or by a workaround such as a
macro like:
(DEFMACRO LAMBDA (LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`#'(LAMBDA ,BINDINGS ,@FORMS)))
Note that unlike the other examples, LAMBDA need not be (and in fact,
may not be) in the "MY" package in order for this to work since the
FUNCTION special form will generally only recognize LISP:LAMBDA.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
The cleanup committee unanimously endorsed this proposal.
In discussion at the Nov-87 X3J13 meeting, Franz and Gold Hill
mentioned that they use this feature a lot and were not entirely
happy about its going away.
∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:37:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:37:58 PST
Date: 14 Feb 88 11:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113758-1303@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: DO-SYMBOLS-DUPLICATES
References: DO-SYMBOLS, CLtL p.187
Category: Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87
Problem Description:
CLtL specifies that DO-SYMBOLS executes the body once for each symbol accessible
in the package. It does not say whether it is permissible for the body to be
executed more than once for some accessible symbols. The term "accessible" is
defined on page 172 to include symbols inherited from other packages (not
including any symbols that may be shadowed). It is very expensive in some
implementations to eliminate duplications that occur because the same symbol is
inherited from multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the body more
than once for some symbols.
Example:
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X))
;; this may print ASYM once or twice.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of duplicates. For
these applications it is unreasonable to force users to pay the high cost of
filtering out the duplications. Users who really want the duplicates to be
removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Cost to implementors:
None. Implemenations would still be free to eliminate the duplications, though
code will not be assuming that this has been done.
Cost to users:
Code written assuming that DO-SYMBOLS eliminates duplications will have to be
modified. (Such code was not truly portable.)
Benefits:
Clarification of a situation that is currently ambiguous.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a clear case
of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and the
solution proposed here seems to have been informally agreed to at the time --
there was no formal decision-making process in place then.
The need for DO-SYMBOLS to be efficient is questionable, however; for many
applications (e.g., global package manipulation), duplicate values would create
havoc.
For some implementations, the performance penalty would be well over a factor of
two.
Several proposals were considered for adding keyword arguments to DO-SYMBOLS
which might specify :ALLOW-DUPLICATES, adding keywords and eliminating
DO-EXTERNAL-SYMBOLS, etc., but no clear consensus was reached for making
additions.
This version is the closest to the status quo.
∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:55:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:55:39 PST
Date: 14 Feb 88 11:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DRIBBLE-TECHNIQUE (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-115539-1321@Xerox>
This issue has not been distributed before. (In fact, this version had not been
distributed to the cleanup committee.) There was no discussion on the issue,
however.
!
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
14-Feb-88, Version 2 by Masinter
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified. Users have
complained that DRIBBLE behaves quite differently in different implementations.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging and that
its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in
different implementations. This makes the status quo much more explicit and will
lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply assigns
streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate
equivalent thereof). Even within this camp, there is not widespread agreement
about which streams are affected. However, typically test case #1 will capture
the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but
not capture its output.
Some implementations (eg, Symbolics) push to a recursive command loop when
DRIBBLE is called with an argument, and return from that command loop when
DRIBBLE is called with no argument. In these implementations, test case #1 will
enter a recursive command loop upon the first call to DRIBBLE and will not
execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second
(DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not
currently being recorded. In test case #2, the output of (PRINT 'FOO) will be
captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE)
does not return normally (it throws).
Cost to implementors:
None. This is just a clarification.
Cost to users:
Anyone who currently uses DRIBBLE in code that is believed to be portable is
kidding himself. If such code works in some implementations, it can continue to
work.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Aesthetics:
No apparent effect.
Discussion:
DRIBBLE, like other environment features, is a standard interface to a
non-standard feature. As such, there is some question as to its place in the
ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made
explicitly vague by this proposal.
∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:01:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:00:15 PST
Date: 14 Feb 88 11:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120015-1323@Xerox>
!
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Cleanup issue DECLARATION-SCOPE.
Cleanup issue DECLARE-MACROS.
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even
though Common Lisp allows declarations in other seemingly analogous places, such
as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations between
the list of local function/macro definitions and the body forms.
The scope of such declarations in FLET and LABELS includes the bodies of the
locally defined functions, when the declarations are pervasive. Non-pervasive
declarations have no effect on those bodies, except when LABELS includes the
body in the scope of a function non-pervasively declared. This paragraph
follows directly from CLtL p.155 if the locally defined function bodies are
treated like initialization forms. (This paragraph will be superseded by cleanup
issue DECLARATION-SCOPE if it passes.)
The scope of such declarations does not include the bodies of the macro expander
functions defined by MACROLET. This is consistent with the existing rule that
the bodies of those functions are in the global environment, not the local
lexical environment.
If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one
of the macros locally defined by that MACROLET is permitted to expand into a
DECLARE.
Example:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this proposal, it
would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make it
possible to attach declarations to function bindings; currently only variable
bindings can have attached declarations.
Current practice:
Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does
not allow declarations in this position.
Cost to Implementors:
The compilation and interpretation of three special forms will have to be
changed, however the same techniques already developed for declarations in LET
should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new special forms
similar to FLET and LABELS and we need to make their syntax consistent with FLET
and LABELS.
∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:03:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:04:24 PST
Date: 14 Feb 88 12:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120424-1324@Xerox>
This issue is new.
!
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, 10-Jun-87
Version 2, Masinter, 15-Jun-87
Problem description:
There are times when users would like to print out numbers with some punctuation
between groups of digits. The "commachar" argument to the ~D, ~B, ~O, ~X, and
~R FORMAT directives was introduced to fill that need. Unfortunately, the
interval at which the commachar should be printed is always every three digits.
This constraint is annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES):
Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth
argument to the ~R directive, to be called the "comma-interval". This value
must be an integer and defaults to 3. When the : modifier is given to any of
these directives, the "commachar" is printed between groups of "comma-interval"
digits.
Test Cases:
Under the proposal, the following forms return the indicated values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale:
The current specification of FORMAT gives the user control over almost all of
the facets of printing integers. Only the wired-in constant for the
comma-interval remains, even though there are uses for varying that number. For
example, in many contexts, it would be convenient to be able to print out
numbers in binary with a space between each group of four bits. FORMAT does not
currently allow specification of the commachar printing interval so users
needing this functionality must write it themselves, duplicating much of the
logic in every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of #\Newline
and a "comma-interval" of, say, 72, very large bignums could be printed in such
a way as to ensure line-breaks at appropriate places.
Current practice:
No released implementations currently support this feature.
Cost to implementors:
The change in the implementation of FORMAT is reasonably minor and, in most
cases, highly localized. Usually, the change is as simple as taking an extra
parameter and using it instead of a wired-in value of 3.
Cost to users:
Since the proposal involves the addition of an argument to certain directives,
the change would be entirely upward-compatible. No user code would need to be
converted.
Cost of non-adoption:
Users desiring this functionality will have to write it themselves, duplicating
much of the logic involved in printing integers at all.
Benefits:
One of the few remaining inflexibilities in integer printing is eliminated with
a net increase in user-visible functionality.
Esthetics:
By parameterizing one of the final pieces of wired-in behavior from integer
printing, this small part of the workings of FORMAT would be perceived as having
been cleaned up.
Discussion:
Several members of the cleanup committee endorsed this proposal. No objections
were raised.
∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:14:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:14:54 PST
Date: 14 Feb 88 12:14 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-121454-1351@Xerox>
This issue is new.
!
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
version 3: Masinter, 5 February 1988
Problem description:
Implementations currently differ on the question of what is tested by the FORMAT
command "~:↑". Some implementations test to see whether any arguments remain in
the sublist for the current iteration step; others test to see whether any
sublists remain. The text on page 406 is not clear on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The
entire iteration process is terminated if and only if the sublist that is
supplying the arguments for the current iteration step is the last sublist (in
the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not*
equivalent to ~:#↑; the latter terminates the entire iteration if and only if no
arguments remain for the current iteration step.
Example:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under this proposal, this yields "a...b", rather than "a".
Rationale:
This proposal is desirable because otherwise there is no way to test whether any
sublists remain. The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
"If one thinks about the intent of the parenthetical `(because in the standard
case it tests for remaining arguments of the current step only)', one should
agree that "a...b" will be returned. In referring to ~↑ as the `standard case',
which tests the arguments remaining in the current argument sublist, this
parenthetical implies that there is an `other case', which tests `something
else.' The only `other case' discussed is ~:↑, which therefore must test
`something else.' I claim that the parentheical makes no sense if we interpret
~:↑ as testing the same condition as ~↑. If they both test the same condition,
why have the parenthetical explanation?
"If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim
that the only test that makes sense is for ~:↑ to test the only thing that
affects the `entire iteration process:' the number of sublists. When there are
no more sublists, `the entire iteration process' is terminated."
Current practice:
Some implementations already have the proposed behavior, including Symbolics
Common Lisp and TI Lisp.
Many other implementations currently have a different interpretation: the test
case returns "a", since ~:↑ in those implementations test for the remaining
arguments rather than remaining sublists. These currently include Kyoto Common
Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
Cost to Implementors:
Many implementations will have to make a small change, probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior of testing for
remaining arguments, but it is possible. The author of this writeup (Steele)
judges it somewhat more likely that user code might depend on the behavior of
testing for remaining sublists.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity. The proposed semantics allows greater
semantic power (there are more things one can test).
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to
test for the remaining arguments.
Historical note: Steele first implemented this "feature", in Zetalisp, and so
the code in Symbolics Common Lisp is likely a direct descendant of the original
code. This might cause some to give weight to Steele's opinion. There are two
arguments against such credence. First, there is no reason why the original
code should be regarded as part of the specification of Common Lisp any more
than any other implementation; plainly, Steele botched the specification when he
wrote the book. Second, a professor of literature (I believe) once told Isaac
Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
Asimov, just because you wrote the story, what makes you think you know what it
means?"
∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:23:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:23:55 PST
Date: 14 Feb 88 12:23 PST
From: Masinter.pa@Xerox.COM
Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122355-1354@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, there is a problem with &KEY lambda variables
because CLtL does not specify how the types specified in the FUNCTION
declaration are matched up to either the actual arguments passed to the
function, or the lambda variables in the function definition (since the ordering
of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
should be supplied as lists of the form (<keyword> <type>). The <keyword> must
be a valid keyword-name symbol as must be supplied in the actual arguments of a
call. (This is usually a symbol in the keyword package, but, as per
KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list.
The interpretation of such declarations is that, when &KEY is given in a
FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
are exhaustive unless &ALLOW-OTHER-KEYS is present.
&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
supplied and, if supplied, may be used.
Example:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and its
matching keyword. All of the information is in one place, and the user does not
have to remember (or even know) the order in which &KEY arguments appear in the
actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type declarations.
The situation regarding type specifications for keyword arguments is so
ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments in
a FUNCTION type specifier may continue to do so. This proposal should not
involve massive amounts of code to be rewritten.
Cost to users:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
The exact semantics of function declarations and the types of arguments is
still under discussion, as are several other issues dealing with declarations.
However, this issue seemed separable.
∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:31:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:29:51 PST
Date: 14 Feb 88 12:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122951-1359@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, this is actually of limited usefulness in the
context of a declaration, where one normally wants type information about the
actual arguments which can be passed to the function rather than the lambda
variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem that
the corresponding type given in the FUNCTION declaration must also be LIST, but
since this provides no information about the actual arguments, some
users/implementors have instead adopted the convention of supplying the type of
the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type
specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with
&REST is the type of each actual argument, not the type of the corresponding
lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be
LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only examples
found so far are in a text book on Common Lisp, which follows the proposed
syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so.
Probably only a small amount of code would have to be written/changed in
implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be
LIST will have to change their code. However, because this issue is so unclear,
the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide the
type of the lambda variable rather than the type of the actual arguments.
However, considering the types specified in the FUNCTION specifier to be the
types of the actual arguments rather than the types of the parameters as seen on
the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee. There was some
support for an alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST
type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry
Masinter) argue that the simplicity of the declarations and the ugliness of the
alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language where
it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if
it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure
case (that doesn't even work in some implementations), it's the sort of thing
that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:58:56 PST
Date: 14 Feb 88 12:58 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-125856-1384@Xerox>
This issue passed conditionally at the June 1987 meeting; this revision was
distributed at the November 1987 meeting.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses GET-SETF-METHOD, and
that macro occurs within a MACROLET, the expansion will not see the MACROLET
definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it defaults to
the null lexical environment. NIL can also be passed explicitly to denote the
null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the environment
to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not apply. A
SETF method applies only when the global function binding of the name is
lexically visible. All of the built in macros of Common Lisp (SETF, INCF, DECF,
POP, ROTATEF, etc.) which modify location specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although some do
not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.
Cost to implementors:
Some implementations will have to add this feature, although it is not a major
change.
Cost to users:
This is generally an upward compatible change. In implementations which did not
already take into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed. The
likelihood of this affecting a user's program is very small.
Benefits:
This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.
Aesthetics:
SETF methods cannot work correctly within lexically defined function symbols
without this change. This change makes the language more consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical environments
as first class objects, including a more general set of accessors and
constructors for lexical environments is required for many language extensions
(e.g., a portable version of the proposed Common Lisp Object System) and should
be addressed by a future proposal. For a while, the cleanup committee attempted
to deal with these issues together, but decided to separate them out into their
component parts. This issue is the simplest.
∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:10:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:10:49 PST
Date: 14 Feb 88 13:10 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 6)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-131049-1395@Xerox>
Version 2 conditionally passed X3J13/Jun87. Version 6 was distributed in
hardcopy form X3J13/Nov87.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 5 by Masinter 8-Oct-87 (explicitly only open)
Version 6 by Masinter 14-Nov-87
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a pathname,
but many sources or sinks of data that streams might be connected to have no
pathnames associated with them; for example, streams created with
MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
simple way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname (as
described on p413 of CLtL) only applies to streams that are originally opened by
use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
to such a stream. It is an error to attempt to obtain a pathname from a stream
created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may be, but is
not required to be, the actual name of the file. The pathname used is the same
as would be returned by the PATHNAME function.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only
thing that can be implemented without large changes to the language such as
extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others
return an empty pathname.
Some implementations do not return a meaningful value for PATHNAME of a synonym
stream.
Adoption Cost:
Implementations that do not currently handle PATHNAME of a synonym stream will
have to change to allow it. Otherwise, since the proposal says only "is an
error" rather than "signals an error", no implementations other changes are
necessary.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to make them
portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
The only point of disagreement on this proposal has been on the issue of whether
PATHNAME applies to synonym streams and returns the pathname of the stream
designated.
This version of the proposal says yes, because CLtL p 329 says about synonym
streams that "Any operations on the new stream ..." and does not say anything
about exceptions; earlier on the page the phrase "synonym streams that pass all
operations on" is used. This seems fairly unambiguous, although the word
"operations" is not defined. There was a similar controversy about what CLOSE of
a synonym stream means.
Note that there is currently no way portable to determine whether a stream has a
pathname available.
The entire PATHNAME section needs work to clarify the intent and enable portable
code. This is just a minor issue among the major ones.
∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:06:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:07:20 PST
Date: 14 Feb 88 13:06 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-130720-1391@Xerox>
Version 6 conditionally passed X3J13/Jun87. Version 8 distributed in hardcopy
form X3J13/Nov87.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
23-Oct-87, Version 7 by Masinter
8-Nov-87, Version 8 by Moon
Problem Description:
CLtL says that only keyword symbols can be used as keyword-names in
&key parameter specifiers (page 60, "each -keyword- must be a
keyword symbol, such as :start.")
As Common Lisp is currently defined, if someone wants to define a
function that accepts keyword (rather than positional) arguments whose
keyword-names are symbols in packages other than the KEYWORD package,
they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the keyword-names of keyword
parameters; allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword symbol with the same print name as the variable is created and
is used as the keyword-name when matching arguments to parameter
specifiers. A keyword-name that is not a keyword symbol can be
specified with the ((-keyword- -var-) ...) syntax of parameter
specifier. The -keyword- can be any symbol, not just a keyword.
A future specification of Common Lisp could be written with revised
terminology that did not use the term "keyword" to refer to three
different things: symbols in the KEYWORD package, symbols beginning
with & that have special meaning in lambda-lists, and keyword-names
used to match function arguments to keyword parameter specifiers.
However, this proposal does not propose to change any terminology.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
keyword-names to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be in the KEYWORD package.
The desire for keyword parameters whose keyword-names are not in the
KEYWORD package arises when the set of keyword-names accepted by a
function is the union of the sets of keyword-names accepted by several
other functions, rather than being enumerated in a single place. In
this case, it becomes desirable to use packages to prevent accidental
name clashes among keyword-names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept arguments and pass
them on to one or more applicable methods, with each method defining its
own set of keyword-names that it is interested in. If this proposal is
not adopted, either the keyword-names will be required to be keywords,
which will require the methods to have non-modular knowledge of each
other in order to avoid name clashes, or the methods will have to be
defined with an ad hoc mechanism that duplicates the essential
functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary arguments from the
caller and passes those arguments along to an internal routine with
additional arguments of its own, and suppose that keyword parameters
are used to receive these arguments.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between "keyword", indicating a symbol
in the KEYWORD package, and "keyword name", indicating a syntactic part
of a keyword parameter specifier. It is likely that this is best served
by changing those instances of "keyword" to "named argument" when the
specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument name must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Cost to implementors:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Cost to users:
None--no existing programs will stop working.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
aesthetic or less aesthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but may be mistaken.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:55:41 PST
Date: 14 Feb 88 12:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 9)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
LINE-FOLD: NO
Message-ID: <880214-125541-1381@Xerox>
This is a difficult issue. The issue was discussed both at the June and November 1987 meetings. There seem to be strong opinions along several different dimensions.
This version of the issue writeup contains two different proposals.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
There are two proposals for dealing with this issue.
!
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
!
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines
the type FUNCTION instead of adding a new type PROCEDURE, and it restricts
coercion by functions that take functions as arguments. The numbering of
CONSERVATIVE is preserved for comparison.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Change FUNCALL and APPLY such that they accept only a function
as the functional argument. This restriction is inherited by
all functions in Common Lispthat take a functional argument.
It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so
"is an error".
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
!
Rationale:
Since the two proposals are similar, they are discussed together. Where
motiviation and justification differ, the proposals are referred to by
name (STRICT-REDEFINITION, CONSERVATIVE.)
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
CONSERVATIVE manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
STRICT-REDEFINITION avoids introducing a new term at the cost of
incompatible change.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what
CONSERVATIVE calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in either. CONSERVATIVE is more compatible with
current practice than STRICT-REDEFINITION, however.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations. While STRICT-REDEFINITION makes it an error to pass
non-function arguments to APPLY, FUNCALL etc, there is no requirement
to check for that error.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The conversion cost associated with CONSERVATIVE is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by CONSERVATIVE, particularly the PROCEDURE
data type, can be converted to fairly lazily.
The conversion cost for the STRICT-REDEFINITION proposal is higher. The
changes to FUNCTIONP and the FUNCTION type declaration is relatively easy
to deal with. However, the strict redefinition of FUNCALL, APPLY and
functional arguments will require the addition of an explicit coercion
would have to be added whenever a symbol or lambda expression is used as
a functional argument. Many such cases can be identified at compile time,
but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might add
run-time test in which the implementation still does the coercion but that
issues a warning message whenever the coercion is actually needed.
Alternatively, a "smart" code-walker or editor macro might find all of the
calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST
or :KEY arguments and, if the argument is not already an explicitly quoted
FUNCTION form, wrap a COERCE around the body.
For either proposal:
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Benefits:
For CONSERVATIVE:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
For STRICT-REDEFINITION:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
STRICT-REDEFINITION provides useful constraints which will be of aid
to systems doing automatic program analysis for the purpose of
``selective linking.'' Such tools may in turn make it possible to
reduce the total size of a delivered application program because
only those Common Lisp functions that are actually called need to be
included.
For either proposal:
The type hierarchy would be simplified.
Either proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
Aesthetics:
Both proposals improve the aesthetics of the language.
Discussion:
These proposals have been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. These two proposals are the distillation of the alternatives.
The CONSERVATIVE proposal offers the advantage of backward compatibility,
and considerably more flexibility in the language.
The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner
resulting language.
Some concerns were raised about STRICT-REDEFINITION in a previous discussion
about "late binding" of function definitions. Neither proposal disallows
late binding of symbols to functions. For example, in the call
(MAPCAR #'FROB my-list)
the effect of the FUNCTION special form (as generated by the #' read macro)
is to obtain the function definition of FROB at the time the #'FROB is
evaluated. Neither proposal changes this.
Currently, it is allowed to write
(MAPCAR 'FROB my-list)
while this form would no longer be allowed under the STRICT-REDEFINITION
clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses
the question of the time at which FROB's function definition is obtained;
if, during the processing of my-list, FROB is redefined, it is not clear
whether the processing of subsequent elements would be changed.
∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:28:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:26:37 PST
Date: 14 Feb 88 13:26 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-132637-1426@Xerox>
My notes are unclear. This issue may have been distributed before.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Version 5 by Masinter 5-Feb-88, fix minor typo
Category: CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a pathname is
expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically, PATHNAME,
TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
REQUIRE are changed by this proposal to not allow symbols for their pathname
argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its pathname
argument. This is implied by the respective descriptions of those functions in
CLtL, but not explicitly stated.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in MacLisp
(which did not have strings) and causes much error-prone behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't
allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation, no
implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where that
works, and they would have to switch to using strings. For example, some users
are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
explicitly allowed in CLtL, so such behavior has not been portable. However,
such use is probably widespread among users of implementations that allow it
(e.g., Common LISPCraft gives this form in an example.)
Benefits:
Pathname functions will be more consistent. In implementations that check the
type of this argument, program error checking will be improved. In dealing with
case-sensitive file systems, users won't do (load 'foo) and wonder why file
"FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
entry that was expected to exist and returned -false-. In systems that accept
symbols as pathnames, this causes a reference to a file named "NIL" on some
perhaps unexpected directory.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error because
it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature of
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not
have strings at all. While the feature was removed from Zetalisp before Common
Lisp was defined due to the poor state of Zetalisp documentation at the time the
change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a
pathname, why can't a symbol be coerced into a pathname? An explicit decision
was made early in the design of CL not to make all coercions transitive. For
example, symbols coerce to strings (for string functions), and strings are
sequences (and so can be mixed with other sequence types), but symbols are not
sequences.
There is some sentiment for extending COERCE to allow explicit coersion of
STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to
allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
disjoint.) While there is some sentiment for making this requirement in a
separate cleanup issue, it would otherwise prevent both symbol->pathname and
stream->pathname to have consistent meaning.
∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:38:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:37:53 PST
Date: 14 Feb 88 13:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-133753-1430@Xerox>
I believe this issue was not distributed before.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Issue SETF-FUNCTION-VS-MACRO.
Category: CLARIFICATION
Edit History: Version 1, 15-Oct-87, Jeff Peck
Version 2, 23-Oct-87, Larry Masinter
Version 3, 8-Nov-87, David Moon
Version 4, 14-Nov-87, Larry Masinter
Version 5, 25-Nov-87, Larry Masinter
Problem Description:
In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be
evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Macros that manipulate generalized variables must guarantee the `obvious'
semantics: subforms of generalized-variable references are evaluated ... in
exactly the same order as they appear in the *source* program. The expansion of
these macros must consist of code that follows these rules or has the same
effect as such code. This is accomplished by introducing temporary variables
bound to the subforms of the reference."
This paragraph and a discussion of SETF on the previous pages may also be
interpreted as requiring that *all* subforms of such macro calls should be
evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice while PUSH
takes care to evaluate them only once."
Place and Item appear in different order in the PUSH form and the indicated
equivalent SETF form. Should the PUSH form have primacy over the obvious SETF
form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or only
those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized variables,
e.g., PUSHNEW, INCF, DECF, and those defined with DEFINE-MODIFY-MACRO.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
This proposal is hard to state, although the intent is fairly clear: evalution
proceeds from left to right whenever possible. The left-to-right rule does not
remove the obligation on writers of macros and define-setf-method to ensure
left-to-right order, however.
In this proposal, a form is something whose syntactic use is such that it will
be evaluated. A "subform" means a form that is nested inside another form -- not
any object nested inside a form regardless of syntactic context.
(1) The evaluation ordering of subforms within a generalized variable reference
is determined by the order specified by the second value returned by
GET-SETF-METHOD. For all predefined generalized variable references (GETF, LDB),
this order of evaluation is exactly left-to-right. When a generalized variable
reference is derived from a macro expansion, this rule is applied *after* the
macro is expanded to find the appropriate generalized variable reference.
This is intended to make it clear that if the user writes a DEFMACRO or
DEFINE-SETF-METHOD that doesn't preserve order, the the order specified in the
user's code holds; e.g., given
(DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
will evaluate <place2> first and then <place1> because that is the order they
are evaluated in the macro expansion.
(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW, GETF,
REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those defined with
DEFINE-MODIFY-MACRO) the subforms of the macro call are evaluated exactly once
in left to right order, with the subforms of the generalized variable references
evaluted in the order specified in (1).
PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP evaluate all
subforms before modifying any of the generalized variable locations. SETF (in
the case when the SETF macro has more than two arguments) performs its operation
on each pair in sequence, i.e., in (SETF <place1> <value1> <place2> <value2>
...), the subforms of <place1> and <value1> are evaluated, the location
specified by <place1> is modified to contain the value returned by <value1>, and
then the rest of the SETF form is processed in a like manner.
(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the generalized
variable reference are evaluted once as in (1), but may be evaluted again if the
type check files in the case of CHECK-TYPE or none of the cases hold in
CTYPECASE and CCASE.
(4) For the macro ASSERT, the order of evaluation of the generalized variable
references is not specified.
(Rules 2, 3 and 4 cover all macros defined in Common Lisp that manupulate
generalized variable references.)
Examples:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
Under this proposal, this would be required to print 12 and not 21.
(LET (X)
(PUSH (SETQ X (LIST 'A))
(CAR (SETQ X (LIST 'B))))
X)
; the PUSH first evalutes (SETQ X (LIST 'A)) => (A)
; then evaluates (SETQ X (LIST 'B)) => (B)
; then modifies the CAR of (this latest value) to be ((A) . B).
; The result is (((A) . B)).
Documentation impact:
PUSH should more appropriately be described as:
"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once, and Item is evaluated
before Place."
The phase "subforms of the reference" which appears several times in CLtL should
be made more specific to be "subforms of the macro call," referring to the
entire form that calls the generalized-variable manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended definition of
"obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In the form
(PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place then Item.
Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Cost to implementors:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost to users:
No currently portable program should be affected. However, this is a minor
incompatible change for some implementations. No serious performance impact is
expected; while some macro expansions may appear to be more verbose, most
compilers deal reasonably with the required order of evaluation.
Benefits:
The implementation and semantics of PUSH become more well specified. This
removes a source of non-portability, abeit likely rare.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this clarification
ensures consistency across the language.
Discussion:
This seems to be the intent of most of the relevant language in CLtL.
For example, the second to last paragraph on page 99
"As an example of these semantic rules, in the generalized-variable reference
(setf reference value), the value form must be evaluated after all the subforms
of the reference because the value form appears to the right of them."
makes it clear that in this context the phrase "generalized-variable reference"
was meant to refer to the entire macro call, not just the Place, and that order
of evaluation rules are not limited to subforms of Places. We hope the
specification should adopt more consistent terminology.
Note that DEFINE-SETF-METHOD is immune to the exception specified about DEFMACRO
and DEFINE-SETF-METHOD, because since CLtL p.103 says about DEFINE-SETF-METHOD:
"This binding permits the body forms to be written without regard for
order-of-evaluation issues."
∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:51:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:49:20 PST
Date: 14 Feb 88 13:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134920-1443@Xerox>
This issue is new.
!
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Dec-87
Version 2 by Pierson 30-Dec-87
Version 3 by Masinter 13-Feb-88
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Example:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
We know of no implementation which currently supports this feature.
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:40:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:41:10 PST
Date: 14 Feb 88 13:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134110-1441@Xerox>
This issue was distributed at the November 1987 meeting.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:54:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:54:43 PST
Date: 14 Feb 88 13:54 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-135443-1454@Xerox>
This issue is new.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Issue AREF-1D
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
5-Feb-88, Version 5 by Masinter
Description:
Common Lisp provides many useful operations on lists and vectors which don't
apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE
the contents of one vector with another, but one can't do this for arrays. One
can verify that EVERY element of a vector has some property, but one can't do
this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up most of
the useful tools CLtL provides for manipulating sequences, even though there is
no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work
on arrays.
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are of
different ranks, so that the two share storage or use the awkward convention of
creating a displaced array to the operand. However, creating a displaced array
merely to perform FILL, REPLACE or EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays of
rank other than 1. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected functions are
LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A
7) should return the same element as (AREF A 0 1 0). :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH.
2) Extend the definitions of sequence functions whose result should be the same
shape as but not necessarily EQ to some argument. These functions should deal
with array arguments by returning an array of the same shape as the argument,
and operate on their argument in row-major order. The affected functions are
SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP.
3) Sequence functions that modify the number of elements in the array remain
unchanged: it is an error to pass arrays of rank other than 1. (The functions
are not extended because the shape would be undefined.) The unaffected functions
are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test whether
the arrays A and B, of different shapes, have the same elements, one might
write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low adoption cost.
Cost to Implementors:
This would involve a lot of changes to functions, but all of the changes are
likely to be minor. The presence of displaced arrays in the language already
guarantees that the internal storage format needed to back up these proposed
changes is already in place.
Cost to Users:
This change is upward compatible; current user code should run unmodified.
Benefits:
This proposal adds natural support for multi-dimensional arrays. Currently,
users must write nested DO loops every time they want to perform an array
operation equivalent to FILL, REPLACE, REDUCE, etc., or else they build
displaced vectors by hand and pass them to the sequence functions when
necessary. With this proposal, users of arrays do not have to use home-grown
utilities to duplicate functionality already primitively provided to users of
arrays. The sequence functions become useful in a variety of new situations.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly avoiding
the temptation to turn Common Lisp into a half-baked APL. Instead of trying to
provide a full set of array handling primitives (which would be needed to take
arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an
operator across a specific dimension of a multidimensional array), it requires
just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what follows is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which didn't
explicitly depend on the shape of the array; that is, to modify COUNT, SOME,
EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and
expressly forbid arrays as arguments to other sequence functions, including
LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT,
MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES,
DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some hedging
over REDUCE and FIND, which often have non-positional uses, were considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been
building displaced vectors to pass to sequence functions when necessary and
really dislikes it.
We considered but discarded as unworkable an alternative where POSITION and FIND
might deal with "positions" as lists of array subscripts.
At one point, this proposal included an extension to COERCE to allow COERCE to
translate from array types to sequences, but it was thought better to separate
out COERCE. We considered a proposal to only introduce a change to COERCE, and
require users who want to operate on arrays explictly perform, e.g., (COUNT
item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost
but was deemed awkward.
Sequence functions like FILL and COUNT are already generalized to arrays in
non-Lisp contexts; in English we use the generalized forms all the time, e.g.,
"count the number of 1's in this matrix."
There is some concern that this proposal makes the requirement for row-major
ordering of internal storage for arrays even more evident. While such an
internal ordering is implied by the ability to create displaced arrays and the
AREF-1D proposal, this proposal adds yet another constraint.
The general reason for opposing this change is that it adds more mechanism than
it is worth. The general reason for liking it is that it adds generality at
little cost.
∂14-Feb-88 1408 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:08:41 PST
Date: 14 Feb 88 14:08 PST
From: Masinter.pa@Xerox.COM
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140841-1482@Xerox>
This issue had not been distributed before.
!
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 01-Mar-87
Version 2 by Masinter 10-Nov-87
Version 3 by Masinter 14-Nov-87
Problem Description:
No information is provided in the description of #+ and #- (pp. 358-359) about
what package the features are read on.
In some systems, the current package is used. Since there is no wording in CLtL
to the contrary, it's reasonable to assume that this would be done, but a
consequence of this is that you must be much more sensitive to the package
you're in at any given time when using #+ or #- even for system-provided
features. (This is a problem if the LISP package can contain only the symbols in
CLtL because system-provided features will likely not have the names of symbols
on LISP and hence will require package prefixes. Having a symbol named
LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
#+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics implementation that
didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This means that
package prefixes are rarely necessary in sharpsign conditionals for
system-provided features regardless of the current package or restrictions about
what may be in LISP. (For example, the KEYWORD package can have any symbol so
it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Specify that the default package while reading feature specs is the keyword
package. Other packages may be designated by use of explicit package prefixes.
Symbols on *FEATURES* may be in any package but that in practice they will
mostly be on the keyword package because that's the package #+/#- uses by
default. If symbols in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package prefixes in the
written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
is KEYWORD.
Rationale:
Making the behavior of #+ and #- well defined is important for people writing
portable code that manipulate *FEATURES* directly.
Current Practice:
Some implementations bind *PACKAGE* while reading feature specs and others do
not.
Adoption Cost:
Changes to implementations to make them conform should be fairly minor if not
trivial.
Benefits:
As currently specified, using #+ and #- in truly portable code can have
bootstrapping problems, since it is sometimes required to conditionally set up
*FEATURES* in different ways for different systems.
Conversion Cost:
Few changes to user code will be required; code that uses #+ and #- will
continue to work, although code that manipulates *FEATURES* directly may require
editing.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL or to certain
implementations.
Discussion:
The cleanup committee supports this proposal.
It might be reasonable to suggest that only vendors should add keyword symbols
to the *FEATURES* list, and that users should add features on their personal
packages so that collisions due to user applications were less likely. This idea
might be a subject of controversy though, so is not part of this proposal.
It would be useful to create a non-binding registry of feature names (and
package names) already in use, so that Lisp implementors could pick otherwise
unused feature names, and users who wanted to write portable code could know
what feature names were preferred.
∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:05:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:04:22 PST
Date: 14 Feb 88 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140422-1472@Xerox>
This issue is new.
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate JonL's suggestions
Version 3 Masinter 26-Oct-87
Version 4 Masinter 10-Nov-87
Problem description:
The description of the SHADOW function can be interpreted as saying that the
function has no effect, if the symbol is already present in the package. This
happens if the third sentence in the description ("then nothing is done") is
interpreted as applying to the entire description rather than just to the fourth
sentence.
SHADOW is said to take symbols as arguments, however only the print-name is
meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as well as
symbols. The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
;;; list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(export 'test-2::test (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when calling the
function USE-PACKAGE. The name conflict is between a symbol directly present in
the using package and an external symbol of the used package. This name conflict
may be resolved in favor of the symbol directly present in the using package by
making it a shadowing symbol. For this to work, SHADOW must add the symbol to
the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string should
also be accepted. This is particularly useful to avoid problems when compiling
code in one package environment and loading it into a slightly different package
environment, where the symbol that was referred to at compile time may not be
present at load time. This is particularly important because the symbol
referred to by the print name may be changed by evaluation of the SHADOW form.
A close reading of CLtL shows that one can already use (shadow '#:bar) in place
of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the
user should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list,
even when the symbol is already present in the package. Kyoto Common Lisp,
Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is
already present in the package. It seems likely that we will find several
implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Cost to implementors:
This should be a minor change to implementations that do not currently work this
way.
Cost to users:
Technically this would be an incompatible change to implementations that do not
already behave as proposed, however it is difficult to conceive of a user
program that would require any conversion to cope with the change. Some users
might want to remove kludges that were only necessary to get around the former
misbehavior of SHADOW.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the name
conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already present
in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL
intended to describe what is being proposed, but unfortunately used ambiguous
language.
The cleanup committee endorses this proposal.
∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:54:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:55:15 PST
Date: 14 Feb 88 14:54 PST
From: Masinter.pa@Xerox.COM
Subject: Common Lisp cleanup issue status to X3J13
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-145515-1510@Xerox>
!
This is the list of issues distributed for the March 1988 X3J13 meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
!
The following issues were mailed prior to the June 1987 meeting and passed at
that meeting; they will not be distributed again except by request.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
!
For your information only, the following issues are still under consideration by
the cleanup committee. Volunteers to help out with the preparation of issue
writeups are welcome. If you would like to review the mail discussion on a given
topic, please let me know and I will forward it to you.
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(Need volunteer.
ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Need volunteer.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
(Change semantics of argument types in function declarations.)
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
beyond SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAST-N (version 1, 4-DEC-87)
(Extend LAST to take an optional N)
Needs rewrite as per Moon
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
(more careful definition of order of evaluation
inside (SETF (GETF ...) ...) )
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88)
Move text of Test case/Example to Problem description.
Somewhere between completely undefining and current situation is
wanted.
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:45:00 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 10:45:09 PST
Received: from sunvalleymall.lucid.com by edsel id AA03090g; Tue, 16 Feb 88 10:16:15 PST
Received: by sunvalleymall id AA28197g; Tue, 16 Feb 88 10:21:23 PST
Date: Tue, 16 Feb 88 10:21:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802161821.AA28197@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: March 1988 agenda questions
I would like to prepare the agenda next week.
If you have something that should be discussed or voted on at the
March meeting please let me know what it is, the Document number
(if any) and approximate time needed.
Thanks!
---jan---
∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 21:22:35 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 21:21:45 PST
Received: from bhopal.lucid.com by edsel id AA05999g; Tue, 16 Feb 88 21:07:02 PST
Received: by bhopal id AA02339g; Tue, 16 Feb 88 21:12:15 PST
Date: Tue, 16 Feb 88 21:12:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802170512.AA02339@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3J13@sail.Stanford.EDU
In-Reply-To: Jan Zubkoff's message of Tue, 16 Feb 88 10:21:23 PST <8802161821.AA28197@sunvalleymall.lucid.com>
Subject: March 1988 agenda questions
The four of us -- smh, rwk, jonl, and rg -- have an issue that needs more
time than a few minutes of cleanup committee covering: the extension of
names for definitions (sometimes referred to as "function specs"). Steve
(Haflich) has the problem description and issues written down, and Bob
(Kerns) has a proposed implementation. It would probably take 10 minutes
to present the issue, and conceivably would be met by 5-20 minutes of
unmitigated flaming from the floor after it is presented.
-- JonL --
∂23-Feb-88 1308 X3J13-mailer Re: voting
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 23 Feb 88 13:06:28 PST
Full-Name: Jim Antonisse
Message-Id: <8802232059.AA18904@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU, jima@mitre.arpa
Subject: Re: voting
In-Reply-To: Your message of 26 Jan 88 14:06:00 -0500.
<[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
Date: Tue, 23 Feb 88 15:59:23 EST
From: jima@mitre.arpa
Bob,
Where exactly *is* the March X3j13 meeting? Does anyone
have details of location, registration fee, etc., figured
out yet? I'll be travelling for the week before it so I'd
like to make all arrangements soon.
Thanks,
Jim Antonisse
MITRE
∂23-Feb-88 1541 X3J13-mailer voting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:37:54 PST
Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 14:57:40 PST
Received: from sunvalleymall.lucid.com by edsel id AA17257g; Tue, 23 Feb 88 14:09:49 PST
Received: by sunvalleymall id AA15130g; Tue, 23 Feb 88 14:15:41 PST
Date: Tue, 23 Feb 88 14:15:41 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802232215.AA15130@sunvalleymall.lucid.com>
To: jima@mitre.arpa
Cc: MATHIS@a.isi.edu, x3j13@sail.stanford.edu, jima@mitre.arpa,
edsel!jlz@labrea.Stanford.EDU
In-Reply-To: jima@mitre.arpa's message of Tue, 23 Feb 88 15:59:23 EST <8802232059.AA18904@mitre.arpa>
Subject: voting
I sent the original message on December 14 but it looks like it's time for
a reminder. Agenda, subcommitte meeting (that I have arranged) and voting
list to follow later this week.
---jan---
X3J13 Meeting and Subcommitte meetings
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-8000. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
*Feel free to bring check to meeting but please let me know if you will be
attending.
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:49 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:24 PST
Received: from sunvalleymall.lucid.com by edsel id AA21834g; Wed, 24 Feb 88 10:49:37 PST
Received: by sunvalleymall id AA17034g; Wed, 24 Feb 88 10:55:36 PST
Date: Wed, 24 Feb 88 10:55:36 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241855.AA17034@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3J13 committee meeting agenda draft
DRAFT
X3J13 Committee Meeting Agenda
March 16 - 17, 1988
1 Call to Order, March 16, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis
- Introduction of attendees
- Report on ISO meeting, Dick Gabriel
- Future meetings and mailings, Jan Zubkoff
3 Approval of Agenda
4 Approval of Minutes
5 CLOS (Doc: 88-002, 88-003, 88-004), Dick Gabriel, Danny Bobrow, et.al.
6 Lunch, 12:00pm - 1:00pm
7 CLOS continuation
8 Recess, 5:00pm
9 Call to Order, March 17, 9:00am
10 Clean-up, Larry Masinter
11 Lunch
12 Status of Standard, Kathy Chapman; 1 hour
13 Function Specs, JonL White, Steve Haflich, Bob Kearns; 20 minutes
14 Condition System, Kent Pitman; 1 hour
15 Other committee reports
16 Adjournment, 5:00pm
∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:37 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:07 PST
Received: from sunvalleymall.lucid.com by edsel id AA21628g; Wed, 24 Feb 88 10:25:19 PST
Received: by sunvalleymall id AA16953g; Wed, 24 Feb 88 10:31:18 PST
Date: Wed, 24 Feb 88 10:31:18 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241831.AA16953@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Subcommittee meetings
Here are the ones I know about.
---jan---
Monday, 3/14
9:00 -
9:30 -
10:00 - CLOS
10:30 - Gabriel
11:00 - Lucid
11:30 - |
12:00 - |
12:30 - |
1:00 - | Characher
1:30 - | Linden
2:00 - | Hyatt Iteration
2:30 - | Delmonte Room White
3:00 - | | Hyatt
3:30 - | | Regency Room
4:00 - | - |
4:30 - | |
5:00 - - -
5:30 -
6:00 -
Tuesday, 3/15
9:00 - Character Clean-up
9:30 - Linden Masinter
10:00 - Hyatt | CLOS
10:30 - Delmonte Room | Gabriel
11:00 - | | Lucid
11:30 - | | |
12:00 - | - |
12:30 - | |
1:00 - | Editorial |
1:30 - | Chapman |
2:00 - | Lucid |
2:30 - | | |
3:00 - | - |
3:30 - | |
4:00 - - |
4:30 - |
5:00 - -
5:30 -
6:00 -
Friday, 3/18
9:00 -
9:30 -
10:00 -
10:30 -
11:00 -
11:30 -
12:00 -
12:30 -
1:00 -
1:30 -
2:00 -
2:30 -
3:00 -
3:30 -
4:00 -
4:30 -
5:00 -
5:30 -
6:00 -
∂24-Feb-88 1140 X3J13-mailer voting at X3J13
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:40:23 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA22000g; Wed, 24 Feb 88 11:07:43 PST
Received: by sunvalleymall id AA17093g; Wed, 24 Feb 88 11:12:40 PST
Date: Wed, 24 Feb 88 11:12:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241912.AA17093@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: voting at X3J13
X3J13 VOTING LIST for March 1988 meeting
Bob's records indicate these groups were represented at the
indicated meetings. If they have paid their X3 service fees,
they can vote at the meeting in Palo Alto.
Company Name Cambridge Ft. Collins
-----------------------------------------------------------
A.I. Architectures x
Aerospace x
Alliant x
Bath U. x x
CSC x
DEC x x
Edinbrugh U. x x
Encore x
Evans and Sutherland x
Franz x x
Gensym x
Gigamos x x
GMD x
Goldhill x x
Gould x
Grumman x x
Hewlett Packard x x
Honeywell x x
IBM x x
ILOG S.A. x
INRIA x
Internat. Lisp Assoc. x
Johnson Controls x x
Lucid x x
Mathis x x
MCC x x
Micro. Sys. Consultants x
MIT x
Mitre x x
NBS x
Prime x
Red Shark Software x
Schlumberger x
Sun x
Symbolics x x
Tektronics x x
Texas Instruments x x
Thinking Machines x x
Unisys x x
USC-ISI x
Wang x
Xerox x x
∂28-Feb-88 1147 X3J13-mailer ISO meeting news
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 11:47:20 PST
Date: 28 Feb 1988 14:46-EST
Sender: MATHIS@A.ISI.EDU
Subject: ISO meeting news
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]28-Feb-88 14:46:29.MATHIS>
Hot news from the ISO-IEC/JTC 1/SC 22/WG 16 Lisp meeting in Paris
February 24-25, 1988.
The working group decided "The draft standard to be provided by
the Working Group within 18 months will take as starting point
COMMON LISP (with X3J13 cleanups) with treatment of major issues
and default values to be identified (including issues in the
AFNOR list and on the agenda)." They also decided on "ISLISP" as
the working name of the standard language.
There is considerable hope in both X3J13 and this ISO working
group that the results of their work match exactly (this will
require close cooperation).
∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:14 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:06:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06854g; Tue, 1 Mar 88 13:56:26 PST
Received: by sunvalleymall id AA00420g; Tue, 1 Mar 88 14:02:49 PST
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803012202.AA00420@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3 attendee list to date
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
---jan---
Registration Fees
03/01/88
Name Company Paid
Masayuki Ida Aoyama Gakuin University -
Gregor Kiczales Xerox PARC -
Bob Mathis -0- -
Daniel Bobrow Xerox PARC y
Kathy Chapman Digital Equipment y
Steve Haflich Franz, Inc. y
Kevin Layer Franz, Inc. y
Thom Linden IBM y
Jeff Rininger SRI International y
Thomas Turba UNISYS Corp y
Walter van Roggen Digital Equipment y
Paul Beiser HP -
Eric Benson Lucid, Inc. -
Jeff Dalton University of Edinburgh -
Linda DeMichiel Lucid, Inc. -
Jerry Duggan HP -
Dick Gabriel Lucid, Inc. -
David Moon Symbolics, Inc. -
Julian Padget University of Bath -
Mary Van Deusen IBM Research -
JonL White Lucid, Inc. -
∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
Received: from potomac.ads.com by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:03:39 PST
Received: by potomac.ads.com (5.58/1.7)
id AA11771; Wed, 2 Mar 88 15:04:38 EST
Date: Wed, 2 Mar 88 15:04:38 EST
From: John T. Nelson <jtn%potomac@potomac.ads.com>
Message-Id: <8803022004.AA11771@potomac.ads.com>
To: ansi-common-request@potomac.ads.com, common-loops-request@potomac.ads.com,
common-windows-request@potomac.ads.com
Subject: Request to be added to mailing list...
We would like to be added to your mailing list. Sorry if I'm repeating
myself but we've had a few problems with ARPAnet. Please send the
common-windows, common-loops and ansi-common lists to their respective
addresses at our machine:
post-common-loops@potomac.ads.com
post-ansi-common@potomac.ads.com
post-common-windows@potomac.ads.com
Thanks.
John T. Nelson UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems Internet: jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
Strange... and beautiful music
∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 13:50:06 PST
Received: from isd1.isi.edu by venera.isi.edu (5.54/5.51)
id AA07388; Wed, 2 Mar 88 13:50:51 PST
Posted-Date: Wed 2 Mar 88 13:50:45-PST
Received: by isd1.isi.edu (5.54/5.51)
id AA09581; Wed, 2 Mar 88 13:50:49 PST
Date: Wed 2 Mar 88 13:50:45-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 attendee list to date
To: edsel!jlz@labrea.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <573342645.0.OHLANDER@VENERA.ISI.EDU>
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
I will be attending the March meeting and will be having lunch on both
days. My registration and fee will follow shortly
Ron Ohlander
USC/ISI
-------
∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:40:12 PST
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 14:01:57 PST
Received: from sunvalleymall.lucid.com by edsel id AA22425g; Fri, 4 Mar 88 14:23:43 PST
Received: by sunvalleymall id AA03806g; Fri, 4 Mar 88 14:30:22 PST
Date: Fri, 4 Mar 88 14:30:22 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803042230.AA03806@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu, paul%hpfclp@hplabs.hp.com
Subject: X3J13 attendee list
Please let me know if you have any additions/changes.
---jan---
X3J13 Attendee Information
03/04/88
Hot
Name Institute Paid L1 L2 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Kathy Chapman Digital Equipment y y y - -
Christopher Dabrowski NBS - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - - - y -
Jerry Duggan HP - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - y -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Ron Ohlander USC/ISI - y y - -
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
Guy Steele Thinking Machines, - y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
-------------------------------
10 25 24 17 6
∂07-Mar-88 1542 X3J13-mailer new and improved list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 15:42:41 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 15:43:20 PST
Received: from sunvalleymall.lucid.com by edsel id AA04874g; Mon, 7 Mar 88 14:59:33 PST
Received: by sunvalleymall id AA09200g; Mon, 7 Mar 88 15:06:23 PST
Date: Mon, 7 Mar 88 15:06:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803072306.AA09200@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: new and improved list
X3J13 Attendee Information
03/05/88
Lunches Sushi Hot
Name Institute Paid 3/16 3/17 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Skona Brittian MSC y y y y y
Kathy Chapman Digital Equipment y y y - -
Pavel Curtis Xerox PARC - y y - -
Christopher National Bureau of - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - y y y -
Jerry Duggan HP - y y - -
Patrick Dussud TI - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Richard Greenblatt Gigamos - y y - -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - - -
Barry Margolin Thinking Machines - y y - -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Jim O'Dell Gigamos - y y - -
Ron Ohlander USC/ISI y y y y y
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
David Slater Computer Sciences - y y - -
Guy Steele Thinking Machines, y y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:21:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae25704; 8 Mar 88 13:12 EST
Received: from csc.ti.com by RELAY.CS.NET id ak03153; 8 Mar 88 13:05 EST
Received: from home by tilde id AA09943; Tue, 8 Mar 88 10:43:52 CST
Received: by home id AA08325; Tue, 8 Mar 88 10:43:27 CST
Date: Tue, 8 Mar 88 10:43:27 CST
From: Ellen Waldrum <waldrum@home.csc.ti.com>
Message-Id: <8803081643.AA08325@home>
To: edsel!jlz@LABREA.STANFORD.EDU, paul%hpfclp@hplabs.hp.com,
x3j13@SAIL.STANFORD.EDU
Subject: Re: X3J13 attendee list
Jan,
I forgot. I will be going to dinner as well. BTW, David Bartley from TI
will be attending. I know he tried to send you a message.
-- Ellen
∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
Received: from HAL.CAD.MCC.COM ([128.62.1.126]) by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:38:22 PST
Date: Tue, 8 Mar 88 15:11 CST
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: X3 attendee list to date
To: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
cc: x3j13@sail.stanford.edu, Loeffler@MCC.COM
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Message-ID: <19880308211108.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
Add:
David D. Loeffler MCC
I have made all my travel arrangements. I will be having lunch on 3/16
and 3/17. I will pay on Wednesday.
-- David D. Loeffler
∂19-Mar-88 1821 X3J13-mailer last meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:21:52 PST
Date: 19 Mar 1988 21:21-EST
Sender: MATHIS@A.ISI.EDU
Subject: last meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:21:18.MATHIS>
Thanks to all of you who participated in last week's meeting. I
think we had a very productive meeting. The results will be in
the minutes and reports from the various committees. The
committees are really working.
I have also noticed that some of you have already begun sending
out comments relative to last weeks discussions. Keep those
cards and letters coming.
Thanks, Bob
∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:44:21 PST
Date: 19 Mar 1988 21:43-EST
Sender: MATHIS@A.ISI.EDU
Subject: minutes 3/88 mtg
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:43:46.MATHIS>
Minutes of the X3J13 Meeting, Palo Alto, March 16, 17, 1988.
Wednesday, March 16
09:00 am Item 1, 2a, 2b., 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2b. Introduction of attendees. Attendees list.
Item 4. Approval of minutes
Item 3. Approval of agenda.
Item 2d. Attendees were reminded to keep discussions short so that
entire agendas could be covered.
The method of distribution for backup will be netmail with
the following exceptions: documents which are too large for
netmail will be mailed, documents will be available in hard
copy at the meeting, and arrangements will attempt to be made
for those people requesting hard cover mailings.
Cambridge, June 13-17. Committee mtg Wed, Thur.
Washington, October, Committee mtg Wed, Thur.
Hawaii, Jan.
09:10 am. Item 2c.
Item 2c. Report on ISO meetings, Paris, Feb 24-25, 1988. Dick Gabriel.
Countries participating were: Canada, Commission of the
European Community, Denmark, France, Germany, Japan,
Netherlands, Switzerland, UK, and US. Position of each
country presented, demonstrating wide diversity of opinion.
US Delegation included Dick Gabriel (project editor), Bob
Mathis, Will Clinger (project editor), Patrick Dussud, Larry
Masinter, Kent Pitman, Thom Linden, and John McCarthy.
Votes were taken which Dick Gabriel stated to the ISO group
had to be tentative on his part since he wished to come back
to this group for advice.
1. Majority vote was to concentrate first on a short-term
standard.
2. Some characteristics of the standard, by preference:
portable, efficient, clear semantics and simple semantics.
3. Most popular departure points were Common Lisp, Scheme,
and Eulisp.
4. The majority vote was for the name ISLISP.
5. Responsibilities were distributed. US volunteered
documents, rather than volunteers, for OOP, Functions,
Macros, Multiprocessing, Character Set, Windows,
Conditions, Iteration. Bob Mathis emphasized to X3J13 that
individuals could volunteer.
10:30 am Break
10:45 am Item 5
Item 5 (Doc: 88-002, 88-003, 88-004), Guy Steele.
Chapter 1 and 2.
The purpose of having an implementation result being undefined
was shown to be that of having the result be undocumented so
that a user could not rely on the result (for example, use of
multiple ELSE in an IF).
JonL White expressed concern that the use of the name "symbol
class" would continue a direction, which he considered
misguided, on nomenclature on symbol-value. A broader
question was raised as one reply that CLOS committee could
not address the entire issue of nomenclature in Common Lisp.
Expressed concerns: voting on chapters 1 and 2 separate from
3; voting on chapters 1 and 2 without knowing how it fits
into CLTL; voting at this meeting rather than waiting until
reply from written comments integrated into chapters 1 and 2;
defining a continuing mechanism (ie. cleanup committee) for
continuing changes to chapters 1 and 2); defining a new
subcommittee to define the layering of Common Lisp.
12:10 pm Item 6 Lunch
1:00 pm Item 7 CLOS Continuation
The following motion was moved and unanimously passed:
X3J13 and the CLOS Subcommittee agree on the following:
1. X#J13 members will read and give comments on Document
88-002 (Chapters 1 and 2 of the CLOS Specification) by April
21, 1988. Comments can be sent via electronic mail to:
common-lisp-object-system@sail.stanford.edu
2. The CLOS Subcommittee will consider all comments, prepare
a revised draft of Chapters 1 and 2, and prepare a written
summary of how they addressed the comments. These documents
will be distributed to X3J13 members in advance of the June
X3J13 meeting.
3. At the June meeting, the X3J13 Committee will vote
whether or not to accept Chapters 1 and 2 out of the CLOS
Subcommittee.
Vote of thanks to the CLOS Subcommittee for their
work was moved and unanimously passed.
Chapter 3.
Gregor Kiczales presented a summary of the status of the
Metaobject Protocol (Chapter 3 of the CLOS Specification
88-003).
Moved by Barry Margolin, seconded by Dan Bobrow.
Approve the general direction of the Metaobject Protocol of
CLOS (as specified in 88-003), and recommend that the Object
Subcommittee continue working on this with an eye toward a
new draft prior to the fall meeting with the expectation that
we would then have a one month written comment period prior
to the winter meeting followed by a vote to move it out of
subcommittee at the winter meeting. Motion passed
unanimously by voice vote.
2:30 pm Afternoon break
2:40 pm Item 10
Item 10 Cleanup, Larry Masinter.
Moved and passed by voice vote 10-7: To postpone the vote on
the bundled cleanup issues until tomorrow morning.
Bundled Issues:
ADJUST_ARRAY_DISPLACEMENT
APPEND_DOTTED
AREF_1D
ASSOC_RASSOC_IF_KEY
COLON_NUMBER
DEFVAR_DOCUMENTATION
DISASSEMBLE_SIDE_EFFECT
DO_SYMBOLS_DUPLICATES
DRIBBLE_TECHNIQUE
FLET_DECLARATION
FORMAT_COMMA_INTERVAL
FORMAT_COLON_UPARROW_SCOPE
FUNCTION_TYPE_KEY_NAME
GET_SETF_METHOD_ENVIRONMENT
KEYWORD_ARGUMENT_NAME_PACKAGE
PATHNAME_STREAM
PATHNAME_SYMBOL
PUSH_EVALUATION_ORDER
REDUCE_ARGUMENT_EXTRACTION
SHADOW_ALREADY_PRESENT
SHARPSIGN_PLUS_MINUS_PACKAGE
Unbundled Issues to be separately considered:
COMPILER_WARNING_BREAK
DECLARE_MACROS
FUNCTION_TYPE_REST_LIST_ELEMENT
FUNCTION_TYPE
SETF_FUNCTION_VS_MACRO
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS
Larry Masinter led a discussion of cleanup issues which were
not sent to members prior to this meeting. For back mail on
a particular issue, send to:
masinter.pa@xerox.com.
Otherwise, see:
cl-cleanup@sail.stanford.edu.
05:05 pm Item 8 Meeting adjourned
Thursday, March 17
09:00 am Item 9
Item 9 Call to Order. Bob Mathis
09:15 am Item 10
Item 10 Cleanup, Larry Masinter
Moved by Dave Slater and seconded by Dan Pierson that the
bundled cleanup issues be accepted in a single vote and
the unbundled cleanup issues be accepted on separate votes.
The motion passed by unanimous voice vote.
COMPILER_WARNING_BREAK - A majority voice vote and a majority
company vote rejected the addition of COMPILER_WARNING_BREAK.
DECLARE_MACROS - Cris Perdue moved and Dick Gabriel seconded
a motion to stop discussion of DECLARE_MACROS. The motion
was passed by majority company vote. A majority company vote
accepted the addition of DECLARE_MACROS.
FUNCTION_TYPE_REST_LIST_ELEMENT - JonL White moved and Barry
Margolin seconded to table the previous motion to accept
FUNCTION_TYPE_REST_LIST_ELEMENT. The motion passed by
company vote 16-7.
FUNCTION_TYPE - Unanimous straw vote showed a belief that
redefinition of some type was necessary (FUNCTION_TYPE).
Unanimous straw vote showed that some change was needed
rather than the status quo. Majority (all but 2) straw vote
showed sentiment was against the conservative proposal.
Majority straw vote passed to not accept 2E as written, but
rather to amend 2E so that FUNCALL and APPLY can accept
anything that can be coerced to a function. A straw vote by
company was called to accept 6B. The straw vote passed
(14-7-4). Barry Margolin moved and Jim Antonisse seconded to
table the previous motion to accept FUNCTION_TYPE and to ask
the subcommittee to resubmit FUNCTION_TYPE with changes in
line with the straw votes. The motion passed (20-1-3). Dick
Gabriel moved and Dan Pierson seconded that the conservative
proposal be immediately accepted. This was unanimously
rejected by company vote (0-25-0).
11:15 pm Break
11:30 pm General comments
SETF_FUNCTION_VS_MACRO - As agreed yesterday, this issue is
tabled until after the function specification report.
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS - The motion to generalize
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS passed (15-6-3). Dick
Gabriel moved and Dan Pierson seconded that the discussion be
reopened. The motion passed by majority company vote. David
Moon moved to call the question to a vote to generalize SEQ
... The vote was rejected (3-18-3).
12:15 pm Item 11 Lunch
01:15 pm Item 12
Item 12 Status of Standard, Kathy Chapman
After describing the phases of document preparation, concern
was expressed whether an early version of the document would
be available or whether the cost in time and money would make
an early version impractical. A straw vote unanimously
passed to require members wishing to review the document to
specifically ask for the document and pay for duplication and
mailing. Kathy has been asked for a more detailed plan for
distribution and review at the next meeting.
02:00 pm Status of Scheme Standard, David Bartley
Scheme standardization is under consideration in a
microprocessor group of IEEE. This umbrella is also working
toward the standardization of MODULA/2, SMALLTALK, FORTH,
and PILOT.
02:15 pm Item 15
Item 15 Other committee reports
MACRO SUBCOMMITTEE REPORT, Julian Padget
There has been no subcommittee meeting since the last X3J13
meeting. Two people responded to a request for interesting
macros. Julian reiterated his request and also asked for new
volunteers. Send any information to:
padget@maths.bath.ac.uk
CHARACTER SUBCOMMITTEE REPORT, Thom Linden
A detailed proposal was presented of the work done to date.
Several strawvotes presented moderate support for the
direction of parts of the proposal.
03:20 pm Break
03:30 pm Announcements, Bob Mathis
03:35 pm Item 15 (cont.)
Item 15 ITERATION SUBCOMMITTEE REPORT, Jon L. White
The status of LOOPS and the work being currently done in OSS
was described. Pavel Curtis discussed ITERATE and GATHERING.
Concern was expressed with the concept of the iteration
constructs being "portable, optional".
COMPILER SUBCOMMITTEE REPORT, Steve Haflich
Steve described a model to be used to figure out what a compile
file does.
04:35 pm Item 14
Item 14 Condition System, Andy Daniels
Comments have stopped so version 18 of proposal seems
stabilized. Open issues are still open but can be completed
as cleanup. Straw vote showed that the directions are right
and that the proposal should be presented for acceptance at
the June meeting. Volunteers are requested to flesh out
specification.
05:00 pm Item 13
Item 13 Function Specs, JonL White
JonL described the overview and goals of the specifications. A
proposal is forthcoming. Unanimous straw vote to encourage
the subcommittee to continue its work and to present a
proposal.
05:35 am Item 10 (cont.)
Item 10 Cleanup, Larry Masinter
SETF_FUNCTION_VS_MACRO - Unanimous straw vote showed that
discussion should be closed. Dan Pierson moved and Guy Steele
seconded the motion to table SETF... The motion passed by a
majority voice vote. Committee thanked Larry Masinter for
bringing forward these issues in such good condition and
Larry thanked his subcommittee.
06:00 Item Adjournment
Minutes submitted by Mary S. Van Deusen (March 17, 1988)
∂21-Apr-88 0708 X3J13-mailer X3J13 Meeting 6/13 - 6/17/88
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 07:08:00 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386470; Thu 21-Apr-88 10:07:49 EDT
Received: by scrc-pegasus id AA00636; Thu, 21 Apr 88 09:48:40 est
Date: Thu, 21 Apr 88 09:48:40 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting 6/13 - 6/17/88
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at
The Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston,
∂21-Apr-88 0829 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 08:29:47 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386565; Thu 21-Apr-88 11:29:22 EDT
Received: by scrc-pegasus id AA01353; Thu, 21 Apr 88 11:19:00 est
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If any has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower faries by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPATURE FROM/DATE/TIME:
AIRLINE PREFERENCE
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 0908 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 09:08:11 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386634; Thu 21-Apr-88 12:07:44 EDT
Received: by scrc-pegasus id AA01584; Thu, 21 Apr 88 11:38:19 est
Date: Thu, 21 Apr 88 11:38:19 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If anyone has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower fares by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
Please feel free to contact me if you have any questions:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
Bouzane@SCRC.Symbolics.Com
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 1242 X3J13-mailer X3J13 Meeting
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Apr 88 12:42:02 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 21 Apr 88 15:20:11 EDT
Received: by kali.think.com; Thu, 21 Apr 88 15:20:07 EDT
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Message-Id: <8804211920.AA20298@kali.think.com>
To: bouzane@scrc-pegasus.arpa
Cc: Symbolics@scrc-pegasus.arpa, x3j13@sail.stanford.edu,
bouzane@scrc-pegasus.arpa
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:19:00 est <8804211540.AA01439@Think.COM>
Subject: X3J13 Meeting
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
∂21-Apr-88 1306 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:06:26 PDT
Received: from HARPAGORNIS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 387047; 21 Apr 88 16:05:18 EDT
Date: Thu, 21 Apr 88 16:04 EDT
From: Tom Parmenter <parmenter@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: gls@Think.COM, stupid@STONY-BROOK.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8804211920.AA20298@kali.think.com>
Message-ID: <19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
Silly boy, it is the Marquis de Sade and he wanted it that way,
with the thumbtacks.
∂21-Apr-88 1352 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:52:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 387207; Thu 21-Apr-88 16:52:15 EDT
Date: Thu, 21 Apr 88 16:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: X3J13@SAIL.Stanford.EDU
cc: Symbolics@PEGASUS.SCRC.Symbolics.COM
In-Reply-To: <8804211920.AA20298@kali.think.com>,
<19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
References: The message of 21 Apr 88 12:38 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 10:48 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Message-ID: <880421165144.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Rosemary Bouzane's inclusion of Symbolics@Pegasus in her messages about
the X3J13 meeting was not really appropriate since most of the recipients
on that list are not involved with X3J13. As such, I'm sure it would
be greatly appreciated by several hundred people if you would NOT cc
that address in any further replies to her message. Send your replies
only to
Bouzane@Pegasus.SCRC.Symbolics.COM
and/or X3J13@SAIL.Stanford.EDU
as appropriate. (And, of course, any replies to this message should
go just to me privately.) Thanks very much.
∂22-Apr-88 0114 X3J13-mailer X3J13 Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Apr 88 01:14:33 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab23998; 21 Apr 88 17:20 EDT
Received: from S51.Prime.COM by EN-C06.Prime.COM; 21 Apr 88 16:25:32 EDT
Received: from ENX.Prime.COM by S51.Prime.COM; 21 Apr 88 16:26:34 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA22731; Thu, 21 Apr 88 16:21:09 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08727; Thu, 21 Apr 88 16:26:28 EDT
Date: Thu, 21 Apr 88 16:26:28 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8804212026.AA08727@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: X3J13 Meeting
>> The next meeting of X3J13 will be held from 8:00 a.m., Monday,
>> June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
>> Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
>> in Boston, MA. The conference room location will be posted
>> on the marquis.
> I hope they use Scotch tape--thumbtacks in his chest will make him
> scream with pain. :-)
>
> (Actually, I *think* that's a typo, though "marquis" and "marquee"
> do happen to be etymologically related.)
I can't resist; since the meeting is in Boston (and with Guy's thumbtacks
to boot) does this make him the "Marquis De Scrod"?
Doug
∂25-Apr-88 1415 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 14:15:35 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 14:15:19 PDT
Received: from sunvalleymall.lucid.com by edsel id AA05247g; Mon, 25 Apr 88 14:03:46 PDT
Received: by sunvalleymall id AA13882g; Mon, 25 Apr 88 14:05:18 PDT
Date: Mon, 25 Apr 88 14:05:18 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804252105.AA13882@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June Meeting addendum and varia
Meeting times for the June meeting:
6/13, 6/14 Monday and Tuesday Subcommittee meetings
6/15, 6/16 Wednesday and Thursday Committee Meeting 9:00 - 5:00
6/17 Friday Subcommittee meetings if necessary
Please let Rosemary know by this Friday, April 29 if you need a
room for a subcommittee meeting. Please let her know:
- name of subcommittee
- date needed
- starting and ending time
- approximately how many people will be attending
If she doesn't hear from you this week she will release the rooms.
We've set the fee for registration at $60.
***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
***Looking ahead, I need a quick head count from those of you who
are seriously thinking about attending the joint X3J13/ISO
meeting in Hawaii in January. Please reply this week, I need to
book the hotel next week.
Thanks.
---jan---
Spring Meeting:
Where: Guest Quarters Suite Hotel
Sub Committee Meetings: 6/13 - 6/14, 6/17 if needed
Committee Meeting: 6/15 - 6/16
Contact: Rosemary Bouzane 617/621-7611
bouzane@scrc.symbolics.com
Fall Meeting:
Where: Contel, 12015 Lee Jackson Highway, Fairfax, VA
Subcommittee Mtgs: 10/10 - 10/11 in Contel Technical Center
Committee Meeting: 10/12 - 10/13 in Contel Auditorium
Contact: Bob Mathis 703/359-0203
mathis@b.isi.edu
Winter Meeting, Joint with ISO:
Where: Kauai, Hawaii
Subcommittee Meetings: 1/17 - 1-18
Committee Meeting: 1/19 - 1/20
Contact: Jan Zubkoff 415/329-8400
edsel!jlz@labrea.stanford.edu
∂25-Apr-88 1830 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 18:30:01 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 18:30:08 PDT
Received: from bhopal.lucid.com by edsel id AA06559g; Mon, 25 Apr 88 18:24:58 PDT
Received: by bhopal id AA29363g; Mon, 25 Apr 88 18:26:52 PDT
Date: Mon, 25 Apr 88 18:26:52 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260126.AA29363@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
re: ***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
I hope this is "4 weeks from subcommittee mailing time", not 2 weeks. Two
weeks before the meeting is May 31, and that is 5 weeks from now. Certainly
there is a lot of work that the cleanup committee will be doing "soon", but
will probably not finish in 2 weeks.
-- JonL --
∂25-Apr-88 1937 X3J13-mailer X3J13 Meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 19:36:46 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 19:36:57 PDT
Received: from bhopal.lucid.com by edsel id AA06593g; Mon, 25 Apr 88 18:28:41 PDT
Received: by bhopal id AA29416g; Mon, 25 Apr 88 18:30:39 PDT
Date: Mon, 25 Apr 88 18:30:39 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260130.AA29416@bhopal.lucid.com>
To: bouzane@scrc.symbolics.com
Cc: sun!clam!loop-groop@labrea.Stanford.EDU, mathis@a.ISI.EDU,
edsel!jlz@labrea.Stanford.EDU
Cc: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu, bouzane@scrc-pegasus
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:38:19 est <8804211745.AA18145@edsel.lucid.com>
Subject: X3J13 Meeting
The Iteration subcommittee will need a room in which to meet; I suspect
that 2-5PM on Monday would be fine. We will be under 10 persons.
-- JonL --
∂26-Apr-88 0848 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 08:48:48 PDT
Received: by labrea.Stanford.EDU; Tue, 26 Apr 88 08:48:52 PDT
Received: from sunvalleymall.lucid.com by edsel id AA09556g; Tue, 26 Apr 88 08:44:00 PDT
Received: by sunvalleymall id AA15756g; Tue, 26 Apr 88 08:45:36 PDT
Date: Tue, 26 Apr 88 08:45:36 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804261545.AA15756@sunvalleymall.lucid.com>
To: edsel!jonl@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jon L White's message of Mon, 25 Apr 88 18:26:52 PDT <8804260126.AA29363@bhopal.lucid.com>
Subject: June Meeting addendum and varia
I'm allowing 1 week slippage, 2 weeks mailing time and 2
weeks for folks to read it.
---jan---
∂27-Apr-88 0100 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 00:59:30 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA25025; Tue, 26 Apr 88 16:05:08 CDT
Posted-Date: Tue, 26 Apr 88 16:04:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25662; Tue, 26 Apr 88 16:04:08 CDT
Date: Tue, 26 Apr 88 16:04:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804262104.AA25662@pavo.src.honeywell.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂27-Apr-88 0104 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 01:04:11 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA24730; Tue, 26 Apr 88 13:53:07 CDT
Posted-Date: Tue, 26 Apr 88 13:52:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA23512; Tue, 26 Apr 88 13:52:08 CDT
Date: Tue, 26 Apr 88 13:52:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804261852.AA23512@pavo.src.honeywell.com>
To: @CIM-VAX.HONEYWELL.COM:edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂28-Apr-88 1315 X3J13-mailer mail to bouzane for June X3 meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 13:15:31 PDT
Received: by labrea.Stanford.EDU; Thu, 28 Apr 88 13:15:40 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02684g; Thu, 28 Apr 88 12:54:12 PDT
Received: by sunvalleymall id AA01699g; Thu, 28 Apr 88 12:55:58 PDT
Date: Thu, 28 Apr 88 12:55:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804281955.AA01699@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mail to bouzane for June X3 meeting
For those of you not able to reply to Rosemary's message try:
bouzane@symbolics.com
∂10-May-88 1438 X3J13-mailer X3J13 June Meeting
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 10 May 88 14:37:53 PDT
Received: from VIRGINIA-RAIL.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256317; Tue 10-May-88 16:55:36 EDT
Date: Tue, 10 May 88 16:56 EDT
From: Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Subject: X3J13 June Meeting
To: x3j13@sail.stanford.edu
cc: x3j13@PEGASUS.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
Message-ID: <"19880510205606.1.bouzane@PEGASUS"@VIRGINIA-RAIL.SCRC.Symbolics.COM>
REMINDER - Deadline for room reservations at the Guest
Quarters Suite Hotel is MAY 12.
Below is registration form - it needs to be completed
ASAP.
The following is the schedule for Subcommittee Meetings:
6/13 - Monday: 2:00-5:00-Iteration Committee
@ Symbolics, Inc.
Eleven Cambridge Center
Cambridge
BONAIRE Conference Room
6/14 - Tuesday: 10:00-5:30-CLOS Committee
@ Symbolics, Inc.
Same address as above
BONAIRE Conference Room
1:00-5:30-Editorial Sub Committee
@ Symbolics, Inc.
Same address as above
ST. CROIX Conference Room
3:00-5:30-Definition Specs Group
@ Symbolics, Inc.
Same address as above
BERMUDA Conference Room
*******************************************************************
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂10-May-88 2005 X3J13-mailer Re: June Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 10 May 88 20:05:10 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab17213; 10 May 88 19:20 EDT
Received: from primerd.prime.com by EN-C06.Prime.COM; 10 May 88 18:36:00 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA01488; Tue, 10 May 88 18:37:12 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08611; Tue, 10 May 88 18:37:30 EDT
Date: Tue, 10 May 88 18:37:30 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8805102237.AA08611@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: Re: June Meeting
Cc: bouzane@SCRC-PEGASUS.ARPA
>> REMINDER - Deadline for room reservations at the Guest
>> Quarters Suite Hotel is MAY 12.
>> Below is registration form - it needs to be completed
>> ASAP.
Can the list of people already registered be posted?
Cheers,
Doug (doug@zaphod.prime.com)
∂16-May-88 1119 X3J13-mailer agenda items please
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88 11:18:26 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:18:29 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25724g; Mon, 16 May 88 11:07:51 PDT
Received: by sunvalleymall id AA28345g; Mon, 16 May 88 11:10:53 PDT
Date: Mon, 16 May 88 11:10:53 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161810.AA28345@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have something that should be listed on the agenda please
let me know what it is and estimate how long you'll need.
Thanks.
---jan---
∂19-May-88 1621 X3J13-mailer mailing deadline approaches
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 19 May 88 16:21:42 PDT
Received: by labrea.stanford.edu; Thu, 19 May 88 16:21:53 PDT
Received: from sunvalleymall.lucid.com by edsel id AA12251g; Thu, 19 May 88 15:59:23 PDT
Received: by sunvalleymall id AA11292g; Thu, 19 May 88 16:02:38 PDT
Date: Thu, 19 May 88 16:02:38 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805192302.AA11292@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mailing deadline approaches
Documents need to be in committee hands by June 1 in order to vote on them at
the June 15-16 meeting. To meet this deadline documents should mailed by
Monday, 5/23. If you don't have your mailing labels yet please call Bob
Mathis ASAP.
---jan---
∂23-May-88 1640 X3J13-mailer June agenda draft
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 16:40:19 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 16:40:43 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02178g; Mon, 23 May 88 16:25:52 PDT
Received: by sunvalleymall id AA02202g; Mon, 23 May 88 16:29:25 PDT
Date: Mon, 23 May 88 16:29:25 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805232329.AA02202@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June agenda draft
Please let me know if there are any changes or additions.
---jan---
X3J13 Committee Meeting Agenda DRAFT
June 15 - 16, 1988
1 Call to Order, June 15, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
6 Character Subcommittee Report, Thom Linden (20 minutes)
7 Iteration Subcommittee Report, Jonl White (15 minutes)
8 Definition Specs Proposal, Jonl White (30 minutes)
9 Lunch, 12:00pm - 1:00pm
10 CLOS discussion and vote (Doc: 88-002R, 88-003R), Danny Bobrow et.al.
11 Recess, 5:00pm
12 Call to Order, June 16, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
∂30-May-88 1838 X3J13-mailer mailing list and next meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 30 May 88 18:38:41 PDT
Date: 30 May 1988 18:33-PDT
Sender: MATHIS@A.ISI.EDU
Subject: mailing list and next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]30-May-88 18:33:39.MATHIS>
Dear X3J13 members and observers:
This letter is a last minute reminder about the upcoming meeting
in Boston and a revalidation of our mailing lists.
You should receive two copies of this letter -- one electronic
and one physical. Our electronic mailing list is at x3j13@
sail.stanford.edu. If you did not receive a copy of this letter
through that means, please notify x3j13-request@sail.stanford.
edu. That is the primary means of communication within this
committee. If you do are not able to access electronic mail,
please notify me at the address on the letterhead. If you did not
receive a physical copy of this letter, please notify me at
Mathis@a.isi.edu.
If you wish to remain on the physical mail distribution list and/
or maintain your membership status on X3J13 you must reply to
this letter (either electronically, by physical mail, or by
attending the upcoming meeting in Boston). The cost of physical
mailings has become substantial. The committee is moving into a
stage where more formal voting will take place and I must be sure
about the membership and fee payment status of each participant.
At the meeting in Boston we will be voting on the final version
of the CLOS documents. These are being physically mailed to you
separately. We will also be considering language issues which are
being distributed electronically (hard copies will be available
in Boston). We will also be considering reports from the
iteration, errors and conditions, character set, editorial, and
other subcommittees. Hard copies of the documents will be
available there. With the exception of the CLOS vote we will be
operating in the kind of "committee of the whole" status we have
been using.
If you have not already made your arrangements for the Boston
meeting (which will be June 13-17), please contact Rosemary
Bouzane, Symbolics, Inc., Eleven Cambridge Center, Cambridge, MA
02142, (617) 621-7611. I will be out of town the week proceeding
the meeting. An alternate contact is Jan Zubkoff, Lucid, 707
Laurel St., Menlo Park, California 94025, (415)329-8400.
Thank you,
Robert F. Mathis
Chairman, X3J13
∂02-Jun-88 1614 X3J13-mailer 88-007
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 16:14:52 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 16:15:16 PDT
Received: from bhopal.lucid.com by edsel id AA02715g; Thu, 2 Jun 88 16:13:01 PDT
Received: by bhopal id AA27781g; Thu, 2 Jun 88 16:11:01 PDT
Date: Thu, 2 Jun 88 16:11:01 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806022311.AA27781@bhopal.lucid.com>
To: x3j13@sail.stanford.edu
Subject: 88-007
Document 88-007 on The LOOP Facility (James Bond Edition?) is intended to
be a draft proposal for specification of the MIT-style LOOP. I cobbled its
text from Lucid documentation, which is being made available to X3J13 free
of any encumbrances. Unfortunately, some mechanically-generated copyright
notice still crept into one page; it should simply be disregarded.
A number of good comments and suggestions for changes have already come in
on this proposal. I will continue to update the text accordingly [unless
and until the editorial committee wants to take it over].
-- JonL --
∂07-Jun-88 1559 X3J13-mailer Issue: FUNCTION-TYPE (version 11)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 15:59:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 15:59:26 PDT
Date: 7 Jun 88 15:59 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 11)
line-fold: NO
Message-ID: <880607-155926-1276@Xerox>
Due to a combination of circumstances, I've been unable to work on cleanup activities. The
committee has proceeded admirably, but I've been behind in summarizing. Since I've been behind,
any decisions made at X3J13 will be preliminary. I will bring some hardcopy of these issues to
the meeting.
However, the issue FUNCTION-TYPE was discussed at length at the last X3J13. This version is our
attempt to recast it according to the wishes expressed at the last meeting.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify FUNCALL and APPLY and all Common Lisp functions that
take functional arguments such that they accept objects that
are coerceable to a FUNCTION as the functional argument. It
is an error if the functional argument is not coerceable to a
FUNCTION.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. Implementations are free to extend the set of objects which
are coerceable to a FUNCTION, particularly lambda-expressions
for compatibility. However, such extensions will not be portable.
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂08-Jun-88 1211 X3J13-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:11:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:07:56 PDT
Date: 8 Jun 88 12:07 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Line-fold: NO
Message-ID: <880608-120756-2864@Xerox>
!
Issue: ADJUST-ARRAY-FILL-POINTER
References: ADJUST-ARRAY (p297)
Category: CLARIFICATION
Edit history: 15-Mar-88, Version 1 by Pitman
Problem Description:
CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill
pointer.
Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL):
Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated
as follows...
If :FILL-POINTER argument is not given, then the fill-pointer of the array
to be adjusted (if any) is left alone. It is an error to adjust an array
to a size smaller than its fill pointer without specifying the :FILL-POINTER
option so that its fill-pointer is properly adjusted in the process.
If supplied, the :FILL-POINTER argument must be either an integer between 0
and the new size of the array, the symbol T (indicating that the new size
of the array should be used), or the symbol NIL (indicating that the fill
pointer should left as it is -- as if the :FILL-POINTER option had not been
specified).
An error is signalled if a non-NIL value for :FILL-POINTER is supplied and
the array to be adjusted does not already have a fill pointer.
Test Case:
(SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ A2 (ADJUST-ARRAY A1 4))
(FILL-POINTER A1) => 3
(FILL-POINTER A2) => 3
(SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1))
(FILL-POINTER B1) => 1
(FILL-POINTER B2) => 1
(SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T))
(FILL-POINTER C1) => 2
(FILL-POINTER C2) => 2
(SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T))
(SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error.
(SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T))
(SETQ E2 (ADJUST-ARRAY E1 4)) is an error.
Rationale:
This behavior must be more clearly defined if portable programs are going
to be able to depend on it.
Current Practice:
Symbolics Lisp implements the proposal. In case "E", it does not signal an
error. It simply leaves the illegal fill-pointer in place so that the
programmer can correct it using (SETF (FILL-POINTER E2) ...)
Cost to Implementors:
Probably most implementations do not deviate significantly from the proposed
behavior. The cost to implementors is probably very slight.
Cost to Users:
None. This clarifies a fuzzy area in the manual which users cannot currently
depend upon.
Cost of Non-Adoption:
The interaction between ADJUST-ARRAY and fill-pointers would continue to be
hazy, and portable programs would not be able to rely upon that behavior
being consistent across implementations.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
There is little if any aesthetic impact of this change.
Discussion:
Pitman volunteered to write this issue up for the Cleanup committee. He's
not very passionate about the details one way or another, but figures it's
a good idea that they be clarified.
The cleanup committee didn't object.
∂08-Jun-88 1237 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:25:42 PDT
Date: 8 Jun 88 12:25 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880608-122542-2920@Xerox>
There's been no discussion (and no objections) to this issue.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, explicitly forbid
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
∂08-Jun-88 1244 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:44:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:39:58 PDT
Date: 8 Jun 88 12:39 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 2)
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880608-123958-2954@Xerox>
There was significant discussion of this issue in the cleanup committee after
Version 2 was distributed, but no revision of the proposal has been produced.
This DRAFT is for your information and discussion at the June X3J13 meeting, but
it is not in final form.
!
Status: DRAFT
Issue: DECLARATION-SCOPE
References: Section 9.1 (pp. 153-157).
Cleanup issue FLET-DECLARATIONS.
Category: CHANGE
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Problem description:
The description of the scope of declarations made with DECLARE is both
unclear (although unambiguous) and arguably a mistake. The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
Proposal DECLARATION-SCOPING:LIKE-VARIABLE:
For the purposes of this proposal, we divide all declarations introduced
with DECLARE into two classes. When a declaration of a variable appears
before the body of a special form or lambda-expression that binds that
variable, the declaration is called `bound'. All other declarations
are called `free'. This division replaces the division into pervasive,
nonpervasive, and SPECIAL declarations appearing in CLtL.
The scope of a `bound' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special.
`Free' declarations are scoped as if they appeared in a new LOCALLY form
which surrounded the entire special form at the beginning of whose body
the declaration appears. This is the same as what CLtL p.155 defines to
be the scope of `pervasive' declarations.
The following is a complete listing of the types of declarations and
their class (`bound' or `free'):
SPECIAL declarations may be either `bound', affecting both a binding and
references, or `free', affecting only references, depending on whether
the declaration is attached to a variable binding, as described above.
TYPE declarations may only be `bound' (see next section).
FTYPE and FUNCTION declarations may only be `free' (see next section).
INLINE declarations may only be `free' (see next section).
NOTINLINE declarations may only be `free' (see next section).
IGNORE declarations may only be `bound'.
OPTIMIZE declarations may only be `free'.
The `free' or `bound' scoping of implementation-dependent declaration
specifiers is implementation-dependent.
Interactions with other proposals:
There has been some discussion in X3J13 of permitting `free' TYPE
declarations. This is a semantic issue, not a scoping issue, and should
be treated independently.
If Common Lisp is extended to permit declarations in FLET and LABELS
forms, by acceptance of cleanup proposal FLET-DECLARATIONS:ALLOW,
then declarations of functions (FTYPE, FUNCTION, INLINE, and
NOTINLINE) which appear before the body of a FLET or LABELS form which
defines that function are `bound'. Such declarations in other contexts
remain `free'.
Common Lisp is ambiguous about whether a variable may be bound several
times by a single form. It has been proposed that multiple bindings be
permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda
expressions. If multiple bindings are permitted, `bound' declarations
are treated as if there were a separate `bound' declaration for each of
the bindings.
Examples:
;;; Some examples of `free' and `bound' declarations.
(let ((a 1))
(declare (optimize speed)) ;this is a `free' declaration
(let ((b 2))
(declare (type integer b)) ;this is a `bound' declaration
(declare (special a)) ;this is a `free' declaration
()))
;;; This example applies if you believe that FLET may have declarations.
(flet ((foo (x) (1+ x)))
(declare (notinline foo)) ;this is a `bound' declaration
(declare (notinline 1+)) ;this is a `free' declaration
())
;;; The following code is from Pavel.
;;; It produces 7 in existing implementations.
;;; If the proposal is adopted, it will produce 8.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let ((foo (1+ foo))) ;is the second FOO special or not?
(declare (special foo)) ;`bound' declaration
foo)))
;;; Treatment of LET* under the proposal if multiple bindings of the same name
are allowed.
;;; This form produces the value 9.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let* ((foo (1+ foo)) ;special binding, lexical reference
(foo (1+ foo))) ;special binding, special reference
(declare (special foo)) ;`bound' declaration, applies to both bindings
foo)) ;special reference
Rationale:
`Bound' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `bound' declarations which were pervasive under the old rules
as it is of those that were not.
Current practice:
The `bound'/`free' division based on context replaces CLtL's static
pervasive/nonpervasive/SPECIAL division. Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
The cost of implementing this change should be moderate. The change
will be localized to a handful of places in the compiler and interpreter
which apply declarations to variables. The other cost would be in
providing tools for users to find programs whose meaning will change.
Cost to Users:
The proposal changes only the treatment of `bound' declarations. This
change will break very few existing production programs.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
The ability of a `bound' declaration to affect code outside the scope
of the variable which it appears to declare has led to endless confusion
and discussion at Symbolics, on the Common-Lisp mailing list, and
elsewhere. It will continue to do so unless it is smoothed over somehow.
Benefits:
The costs of non-adoption will be avoided.
Aesthetics:
The distinction between `bound' and `free' declarations introduced by
this proposal is a natural one.
Discussion:
A proposal to forbid `free' declarations except in LOCALLY forms and a
proposal to have `free' declarations affect only the body were discarded
as being too incompatible.
The mapping from the existing pervasive/nonpervasive/SPECIAL division of
declarations and the one proposed here is complex. In general,
nonpervasive declarations are `bound' and pervasive declarations are
`free'. SPECIAL declarations are either `bound' or `free' based on
their context, and are no longer treated as a special case.
Some historical support for having `free' and `bound' declarations:
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
...
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
...
∂08-Jun-88 1509 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:09:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:09:25 PDT
Date: 8 Jun 88 15:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-150925-3305@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error. Checking for it
would be costly so signaling this error is not required.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1524 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:19:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:12:04 PDT
Date: 8 Jun 88 15:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-151204-3312@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References: CLtL p.307 & 86-003 p.4
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
Structures defined by defstruct currently are required to have at least
one slot. This seems to have been a mistake in the design of the language.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.
Test Case:
(defstruct s), which is not allowed according to CLtL, would be allowed.
Rationale:
The current restriction is in marked contrast to the generality allowed
elsewhere in the language. And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.
Current Practice:
KCL allows zero slots.
Cost to Implementors:
None for implementations that currently allow zero slots.
Very slight for others.
Cost to Users:
None.
Benefits:
Slightly increases the usefulness of defstruct and is aesthetic.
Aesthetics:
In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case. And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1531 X3J13-mailer Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:31:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:24:52 PDT
Date: 8 Jun 88 15:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-152452-3341@Xerox>
!
Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References: CLtL p.308-10 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.
On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot. If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."
On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.
Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.
In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".
To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Test Case:
In the following sequence, only the last call is an error.
(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)
Rationale:
It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.
Any existing confusion should be clarified by this proposal.
Current Practice:
KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.
Cost to Implementors:
If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.
Cost to Users:
None.
Benefits:
Clarity and portability. In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.
Aesthetics:
It appears slightly unaesthetic to have a default value that violates a
type specification.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
!
Additional notes:
Several members of the cleanup committee endorsed this proposal.
JonL added:
You can add to the "Current Practice:" section:
LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.
Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked. Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.
I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization). Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED." However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.
∂08-Jun-88 1806 X3J13-mailer Issue: EVAL-OTHER (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 18:06:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 18:03:17 PDT
Date: 8 Jun 88 18:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-OTHER (Version 2)
To: X3J13@SAIL.Stanford.EDU
reply-to: CL-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <880608-180317-3640@Xerox>
I have some notes about some possible additional opposition to this proposal. I hope
we can discuss it at the June X3J13 meeting.
!
Issue: EVAL-OTHER
References: 5.1.1 Self-Evaluating Forms (p55)
Category: ADDITION/CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
Problem Description:
CLtL does not specify what the evaluation behavior of some data types.
Proposal (EVAL-OTHER:SELF-EVALUATE):
Standard data types (those mentioned by CLtL) other than those for which
a more explicit evaluation rule exists would be defined to self-evaluate.
Such data types include, for example, structures, arrays, vectors, and
pathnames.
Structure types defined by users using DEFSTRUCT should also self-evaluate
unless an explicit implementation type for the structure is given in the
DEFSTRUCT, in which case the rule for evaluation of that type should be
used. (This is important in the case of type LIST.)
Test Case:
(LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T
(LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
Rationale:
There are numerous possible positions that could be taken, from
requiring that an error be signalled for all of these cases to
requiring that these all have some useful behavior.
By making implementations agree, code portability is enhanced.
By biasing the decision away from the "signal
an error" end of the choice spectrum, the least interruption is
caused to implementations which already have working code.
There is still some chance that implementations will have some other
behavior than either signalling an error or self-evaluating, but there
are probably few if any.
Current Practice:
In many implementations, the other data types besides those mentioned in
CLtL will self-evaluate.
Cost to Implementors:
The cost is probably small. This is probably an "upward compatible"
change for most or all implementations -- a few lines of change in the
interpreter and/or compiler. Some code walkers may be affected as well.
Cost to Users:
None, if they are not exploiting implementation-dependent features of
some implementation that is being forced to make an incompatible change.
There should be no performance impact since the evaluator's test for these
new data types can simply be made to follow other tests already in place,
so existing code will not be slowed.
Cost of Non-Adoption:
Implementations will continue to differ in this relatively
user-visible way.
Benefits:
Portability will be enhanced because implementations will tend to agree
in places where they have traditionally not always agreed.
Aesthetics:
Some fans of 3LISP may find this invasive to their sense of distinction
between objects and the notation used to describe objects. In general,
however, this is a fairly picky detail that is not likely to trouble the
average programmer.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.
Fahlman: "... I do remember the original design discussions. It was
proposed that everything but lists and symbols evaluate to themselves,
but at the time (this was quite early in the process) some people felt
that this might close out interesting parts of the design space that
might turn out to be useful for something. This hasn't happened, and
I think it would be reasonable to close this door now. Some users do
find it confusing that you have to quote vectors but not strings."
There has been some additional discussion of this proposal (for example,
an explaination of why a similar proposal in Scheme might be a bad design.)
∂08-Jun-88 1752 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 17:51:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 17:47:35 PDT
Date: 8 Jun 88 17:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 2)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-174735-3615@Xerox>
This issue is a DRAFT; I hope that discussion at X3J13 can help the cleanup committee focus on the most popular options.
!
Status: DRAFT - for discussion at June X3J13
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (add Benson's proposal)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:RADICAL):
Remove EQUAL and EQUALP from the language. (Naturally, they could be retained
as implementation-dependent extensions.)
Rationale:
The name "EQUAL" suggests something very generic. It conjures in the mind
of the naive user the notion that there is a single, uniquely selected
predicate which is always good for equality testing. In fact, there is a
large space of useful equality predicates, each good for different
applications, and the choice of the current definition of EQUAL is
exceedingly arbitrary. Although the function chosen is sometimes quite
useful and some work is occassionally saved by having it be defaultly
available, confusion frequently results from its presence. Users for whom
the operator is not appropriate are inclined to describe it as broken,
rather than to recognize that it does a useful thing but that the
application they have does not call for that useful thing. The thing which
would be useful to them would not be useful in other situations. There is
simply no unique solution. The absence of the operator EQUAL would cause
people to think explicitly about what kind of equivalence is appropriate
to their application, and to write something better suited to that
application.
As an aside, this same notion of uniqueness carries over to COPY. People
have been observed to assert that a generic COPY function should be
present for copying arbitrary objects. A single COPY function is not
provided because there are many kinds of copying and no single function is
entitled to the generic name COPY. This argument does not sit well with
programmers who assert that if this is true, there should be no unique
EQUAL operator. We could solve that problem two ways -- one by creating a
COPY operator; another by eliminating the embarrassment of EQUAL and
friends.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Leave things as is.
Rationale:
The intent of a structure is different than the intent of an array. A
list is an anonymous entity which makes sense only in terms of its
length and contents, and is not rightly compared just by object identity
(EQ); a structure, on the other hand, has an identity of its own and is
appropriately compared with EQ.
Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
Rationale:
A structure is a container and, like many other containers in Lisp,
should be compared by recursing into the contents of that container.
Proposal (EQUAL-STRUCTURE:ADD-KEYWORDS):
Add :TEST and :TEST-NOT keywords to EQUAL saying what comparison operator
to use at the leaves.
[This will need more details if anyone decides they want to push this line
of reasoning. I don't claim to have done an adqeuate job of laying the
issue out, though I could imagine someone doing so. -kmp]
Rationale:
There's ample precedent for resolving sticky situations like this in
Common Lisp by just adding a keyword option. :-)
Proposal (EQUAL-STRUCTURE:ADD-OPERATOR)
Introduce new operator(s) like EQUAL (and/or EQUALP) which descends
structures.
Rationale:
If people don't want to make EQUAL more complicated, but still like
the idea of a keyword-driven EQUAL, this is the only way to get it.
Proposal (EQUAL-STRUCTURE:CHANGE-EQUALP):
Change EQUALP so that it descends structures, is case sensitive, and
never considers numbers of different types to be equal.
Rationale:
Several users have independently inquired why there is no predicate
with this definition in Common Lisp. Also, use of EQUALP is not
widespread. Rather than invent a new name for a predicate, it
would be preferable to take an existing name which is not being
heavily used and give it a more useful definition.
It would also be useful to have EQUALP type hashtables, given this
new definition for EQUALP.
EQUALP did not exist in Lisp dialects preceding Common Lisp. There
are few programs that make use of EQUALP and only those depending
on case insensitivity or numeric coercion (or lack of structure
descending) would be affected.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Current Practice:
There is no particular ambiguity in CLtL right now, so presumably
everyone agrees. The only question is whether what CLtL says is
sufficiently useful in practice.
Cost to Implementors:
The cost to implementors of most of these options is generally small.
The exception is that the ADD-KEYWORDS option may require hairy compiler
optimizations in order to get back the efficiency that a keyword would lose.
Cost to Users:
Writing an EQUAL or EQUALP function which is like the one that Common Lisp
now has would not be that hard to do as a compatibility measure in case
EQUAL or EQUALP were changed or removed. So the cost to users is technically
small.
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
Aesthetic considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
The ADD-KEYWORDS option will be the most controversial because some people
don't like keywords and some compiler writers will not like having to
optimize the keywords.
Discussion:
Pitman strongly supports EQUAL-STRUCTURE:RADICAL as the correct choice from
a purely language design standpoint, but acknowledges that it may not
ultimately be deemed practical for pragmatic reasons.
Eric Benson supports EQUAL-STRUCTURE:CHANGE-EQUALP. He has never
used EQUALP in a "serious" program, but in every "casual" use he has
wished that it was case sensitive.
∂08-Jun-88 1918 X3J13-mailer Issue: DEFPACKAGE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:17:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:17:03 PDT
Date: 8 Jun 88 19:16 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFPACKAGE (version 2)
To: X3J13@Sail.Stanford.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-191703-3760@Xerox>
This issue is still a DRAFT. The ongoing discussion, however, centers
around the details of the operations of some of the keyword arguments
(e.g., should :IMPORT-FROM take strings instead of/as well as symbols.)
!
Status: DRAFT - for discussion at June 1988 X3J13 meeting
Issue: DEFPACKAGE
References: CLtL section 11.7.
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
package-name is a symbol or a string; if a symbol, only its name
matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
Standard options for DEFPACKAGE are listed below. Additional options
might be present in an implementation, and each implementation must
signal an error if an option not recognized by that implementation is
present. Additional implementation-dependent options might take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:EXPORT {symbol}*)
Create symbols with the specified names and export them.
Note that only the name of each argument symbol is used.
The symbol that gets exported is not necessarily the one given
as an argument; it's a symbol with that name but in the package
being defined.
(:IMPORT {symbol}*)
Import the specified symbols.
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified strings.
(:SHADOW {symbol}*)
Create the specified symbols in the package and place them on
the shadowing list. Note that only the name of each argument
symbol is used.
(:SHADOWING-IMPORT {symbol}*)
Import the specified symbols into the package and make them
shadow any inherited symbols.
(:SHADOWING-IMPORT-FROM {(package-name {symbol}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined, making them shadow any
inherited symbols. The second syntax is a convenient
abbreviation when only one package is specified. Note that only
the name of each argument symbol is used. The actual symbol
that gets imported is not necessarily the one given as an
argument; it's a symbol with that name accessible in the named
package.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
(:USE {package}*)
Inherit from the specified packages.
Example:
(DEFPACKAGE MY-PACKAGE
(:USE LISP)
(:SHADOW CAR CDR CONS)
(:NICKNAMES MYPKG MY-PKG))
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had this, and uses it in preference
to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version
of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" business
described at the end of chapter 11 could be removed, and the special
compiler handling of these functions necessary to support that could be
removed. As this would be an incompatible change, it is not part of
this proposal.
KMP suggests that IN-PACKAGE should be incompatibly changed only to
recognize existing packages, not to create them, which would fix a lot
of bugs. IN-PACKAGE would then not accept any keyword arguments.
Moon thinks this is a reasonable idea but should be the subject of a
separate proposal.
∂08-Jun-88 1946 X3J13-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:46:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:45:16 PDT
Date: 8 Jun 88 19:44 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
to: X3J13@Sail.Stanford.Edu
reply-to: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-194516-3779@Xerox>
The only discussion on this issue was a revisiting of the various hiding places
in CLtL where it states requirement that function arguments evaluate from
left to right.
!
Issue: FUNCTION-CALL-EVALUATION-ORDER
References: CLtL p 194 ("...that order is always left to right")
Category: CLARIFICATION
Edit history: Version 1 by Clinger (22 March 1988)
Problem Description:
CLtL does not say whether the function expression of a call is evaluated
before or after the argument expressions.
Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
Common Lisp does not specify whether the function expression of a call is
evaluated before or after the argument expressions. Programs that rely on
a particular order of evaluation are in error.
Example:
(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))
; may return 23 or 24
Rationale:
This makes the status quo explicit.
Current Practice:
TI and Symbolics evaluate the function expression last. Lucid and Coral
sometimes evaluate the function expression first and at other times evaluate
the function expression last.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Codifies an ambiguity.
Aesthetics:
Since Common Lisp evaluates argument expressions from left to right, it would
be more consistent for the function expression to be evaluated before the
argument expressions. On the other hand, the evaluation rules for function
expressions are already quite different from the rules for argument
expressions, and nobody in their right mind would write code that depends on
the order of evaluation, so aesthetics should not count for much in this case.
Requiring left to right evaluation would force some implementations to consume
an extra register for many function calls. The efficiency argument seems more
important than the aesthetic argument.
∂08-Jun-88 1958 X3J13-mailer Issue: LAST-N (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:58:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:57:18 PDT
Date: 8 Jun 88 19:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LAST-N (Version 2)
To: x3j13@SAIL.Stanford.EDU
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-195718-3790@Xerox>
!
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
12-Mar-88, Version 2 by Pitman
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
The default for N would be 1.
It is an error if N is negative or L is circular.
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in the list
L, then the result is L.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) => (A . B)
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
Masinter opposes this extension as gratuitous.
Moon and Daniels think this is very low priority but have expressed a
lack of major objection to this proposal.
∂08-Jun-88 2030 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:30:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:29:25 PDT
Date: 8 Jun 88 20:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
to: X3J13@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-202925-3823@Xerox>
This draft is for discussion at the June 1988 X3J13 meeting.
!
Status: DRAFT
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
∂08-Jun-88 2049 X3J13-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:49:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:48:16 PDT
Date: 8 Jun 88 20:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
To: x3J13@SAIL.Stanford.Edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-204816-3838@Xerox>
!
Issue: MACRO-FUNCTION-ENVIRONMENT
References: MACRO-FUNCTION, p. 144
MACROLET, pp. 113-4
&ENVIRONMENT, pp. 145-6
MACROEXPAND and MACROEXPAND-1, pp. 151-2
Category: ADDITION
Edit history: Version 1, Pavel, March 21, 1988
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
Problem description:
The &ENVIRONMENT argument to a macro-expansion function may only be used as the
second argument to the functions MACROEXPAND and MACROEXPAND-1. It is sometimes
more convenient, however, to be able to work directly with the more primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably
based. However, since MACRO-FUNCTION does not take an environment argument, it
cannot be used in situations in which that environment must be taken into
account.
Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):
Add an optional second argument to MACRO-FUNCTION, that argument being an
environment that was passed as the &ENVIRONMENT argument to some macro expansion
function. If the argument is not given, or the argument is NIL, the null
environment is used. MACRO-FUNCTION will now consider macro definitions from
that environment in preference to ones in the global environment. It is an error
to supply the environment argument in a use of MACRO-FUNCTION as a SETF location
specifier.
Examples:
(macrolet ((foo (&environment env)
(if (macro-function 'bar env)
''yes
''no)))
(list (foo)
(macrolet ((bar () :beep))
(foo))))
=> (no yes)
(setf (macro-function 'bar env) ...) is an error.
Rationale:
Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one. By changing this
state of affairs, the model of macro expansion becomes somewhat simpler. Also,
more flexible use of the facility is enabled.
Current practice:
Xerox Common Lisp already implements this proposal. Symbolics Common Lisp,
and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0 does.
Cost to Implementors:
This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
Cost to Users:
The change is upward-compatible and so poses no cost to users.
Cost of non-adoption:
One more (small) semantic wart on the language.
Benefits:
The function that users think of as being more primitive really is.
Aesthetics:
This slightly cleans up the language.
Discussion:
This issue was discussed starting in January 1987, but got tangled in
a web of other related proposals. In its current form, the only objections
have been that some other proposal or committee might otherwise change
macro handling, or that this proposal doesn't fix enough of the problems.
∂08-Jun-88 2058 X3J13-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:57:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:57:13 PDT
Date: 8 Jun 88 20:57 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
line-fold: no
Message-ID: <880608-205713-3851@Xerox>
!
Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
Version 5, 7-Jun-88 Masinter (more nits)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Minor impact.
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
∂08-Jun-88 2103 X3J13-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 21:02:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 21:02:13 PDT
Date: 8 Jun 88 21:01 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-210213-3853@Xerox>
!
Issue: SUBSEQ-OUT-OF-BOUNDS
References: :START and :END arguments (246-247), SUBSEQ (248)
Category: CLARIFICATION
Edit history: 24-Mar-88, Version 1 by Steele
29-Mar-88, Version 2 by Steele, in response to Moon's comments
Problem description:
The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices. (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)
Also, the language on page 246 does not make clear whether the prohibition
against "start > end" applies to defaulted values as well as explicit
values, and does not specify clearly whether the default value for the
end argument is the allocated length or the active length.
Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero.
Specify that it is an error for the :END argument of any standard function,
or the third argument to SUBSEQ, to be greater than the active length of
the sequence in question (as returned by LENGTH).
Specify that the start value, after defaulting, must not be greater than
the end value, after defaulting.
Specify that the default value for the end argument is the active length of
the sequence in question.
This may be summarized as follows:
Let X be the sequence within which indices are to be considered. Let S be
the :START argument of any standard function, or the second argument to
SUBSEQ, whether explicitly specified or defaulted, through omission, to
zero. Let E be the :END argument of any standard function, or the third
argument to SUBSEQ, whether explicitly specified or defaulted, through
omission or an explicitly passed NIL value, to the active length of X, as
returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X))
is not true.
Test Cases/Examples:
(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.
Rationale:
We don't want code indexing off the ends of arrays.
Current practice:
KCL interpreted and compiled code signals an error.
Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).
Lucid Common Lisp interpreted and compiled code signals an error.
Cost to Implementors:
None.
Cost to Users:
Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is now officially
unportable.
Cost of non-adoption:
Confusion.
Benefits:
Removal of a small but important ambiguity in the spec.
Esthetics:
It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.
Discussion:
This merely clarifies the original intent of the passage on page 246.
∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 07:14:29 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 9 Jun 88 10:11:00 EDT
Received: by kali.think.com; Thu, 9 Jun 88 10:10:57 EDT
Date: Thu, 9 Jun 88 10:10:57 EDT
From: gls@Think.COM
Message-Id: <8806091410.AA03128@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Masinter.pa@xerox.com's message of 8 Jun 88 19:57 PDT <880608-195718-3790@Xerox>
Subject: Issue: LAST-N (Version 2)
I cast a "grue" vote for LAST-N:ALLOW-OPTIONAL-ARGUMENT; that is,
I support it and will continue to support it until it has consumed
either ten more messages on this mailing list or ten minutes of
meeting time, after which I will fiercely oppose it.
--Guy
∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jun 88 09:03:36 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02943; 9 Jun 88 10:01 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa07565;
9 Jun 88 10:00 BST
To: cl-cleanup@sail.stanford.edu
CC: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-reply-to: Masinter.pa@com.xerox's message of 8 Jun 88 15:07 PDT <880608-150925-3305@Xerox>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Date: Thu, 9 Jun 88 10:02:42 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>>Rationale:
>>
>>Since it would be difficult to prescribe reasonable behavior for
>>this situation, it should be considered an error. Checking for it
>>would be costly so signaling this error is not required.
Sorry, I do not see the great cost. Surely defstruct is in effect a
declaration, and the cost of checking is small and the value great.
==John
∂09-Jun-88 1043 X3J13-mailer [bouzane@scrc-pegasus: X3J13 Meeting]
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 10:43:22 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 10:42:22 PDT
Received: from challenger.lucid.com by edsel id AA14871g; Thu, 9 Jun 88 10:37:09 PDT
Received: by challenger id AA12537g; Thu, 9 Jun 88 10:34:58 PDT
Date: Thu, 9 Jun 88 10:34:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8806091734.AA12537@challenger.lucid.com>
To: x3j13@sail.stanford.edu
Subject: [bouzane@scrc-pegasus: X3J13 Meeting]
We only have 34 people registered for X3J13 in Boston. Rosemary needs to know
how many will be at lunches. Please let her know if you will be attending but
haven't let her know yet. If you are unable to reach her please conact me and
I will pass on the information.
---jan---
Registered Attendees:
Arbaugh, William - US Army
Antonisse, H. James - Mitre Corp.
Bartley, David - Texas Instruments
Beiser, Paul - Hewlettt & Packard
Boelk, Mary P. - Johnson Controls
Chapman, Kathy - Digital
Dabrowski, Chris - Nat'l Bureau of Standards
DeMichiel, Linda - Lucid
Dussud, Patrick - TI
Gabriel, Dick - Lucid
Hadden, George, Honeywell
Haflich, Steve - Franz, Inc.
Hewitt, Carl - MIT AI Lab
Keene, Sonya E. - Symbolics, Inc.
Kiczales, Gregor - Xerox Parc
Larson, Aaron - Honeywell
Linden, Thomas - IBM Almaden Research
Loosemore, Sandra - Evans & Sutherland
Mathis, Robt.
Mikelsons, Martin - IBM
Moon, David A. - Symbolics, Inc.
Perdue, Crispin - Sun
Pierson, Dan - Encore
Piazza, Jeffrey - Digital
Rand, Douglas - Prime Computer
Rosenking, Jeff - Grumman Corp
Saji, Nobuyuki - NEC Corp
Slater, David - Computer Sciences Corporation
Van Roggen, Walter - Digital
Van Deusen, Mary - TI
Waldrum, Ellen - Texas Inst.
White, Jon - Lucid
Zubkoff, Jan - Lucid
∂09-Jun-88 1525 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 15:25:08 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 15:24:07 PDT
Received: from bhopal.lucid.com by edsel id AA16555g; Thu, 9 Jun 88 15:19:42 PDT
Received: by bhopal id AA25468g; Thu, 9 Jun 88 15:18:17 PDT
Date: Thu, 9 Jun 88 15:18:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806092218.AA25468@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, labrea!cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 12:39 PDT <880608-123958-2954@Xerox>
Subject: Issue: DECLARATION-SCOPE (Version 2)
Did you really want to distribute this to the X3J13 committee as a whole?
I had proposed a major rewrite of this issue, based on treating DECLARE
simply as a lexical construct, but haven't had the time to work on it before
the upcoming meeting. I'd hoped to see cleanup subcommittee discuss it
again before bringing the issue to the committee as a whole.
-- JonL --
∂09-Jun-88 2119 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:19:30 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:17:29 PDT
Received: from bhopal.lucid.com by edsel id AA17893g; Thu, 9 Jun 88 21:10:37 PDT
Received: by bhopal id AA26479g; Thu, 9 Jun 88 21:09:17 PDT
Date: Thu, 9 Jun 88 21:09:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100409.AA26479@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 17:47 PDT <880608-174735-3615@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 2)
I thought you were going to incorporate my comments into this issue, which
I sent in reply to its first presentation:
Date: Fri, 18 Mar 88 21:21:51 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Generally ok write-up of the issues. You left out the option of adding
a jillion-skillion new functions -- one for each conceivable kind of
equivalence relation between s-expressions. But that's ok; I want to
focus on just one of your proposals.
re: Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
EQUALP is already documented to descend structures (CLtL, p81). So this
proposal should just say "Change EQUAL ...".
Had all the negative arguments against this particular proposal -- the one
you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could
not even have an EQUALP function. The logical conclusion of these
"technical details" arguments is that EQUAL cannot be defined either.
These arguments go roughly as follows:
(1) The equivalence which EQUAL implements is not graph-isomorphism --
which *is* uniquely defined -- but rather an ill-defined one
making reference to the underspecified notion of "printing".
Attempts to make it more precise are merely arbitrary.
(2) EQUAL is not a total function since it is permitted to run amok
on circular structures. In fact, it is much more "likely" that
defstruct instances will contain ultimately circular links than
that cons cells will; hence one will "probably" lose more much
often if EQUAL were to descend structures.
The more "wizard", or "theorist" one is, the more compelling the above
arguments seem. On the other hand, the more a "user" one is, the more
likely he will argue as follows:
I've used the EQUAL function for over 15 years, and have almost never
been dissatisfied with it, as the Doctors of Technology say I should be;
and every instance of dissatisfaction was due to its failue to descend
through pointer vectors. I keep my house in order, and know exactly
how my data pyramids are built up; so why should I be punished just
because some Conehead somewhere got lost playing around with his
Klein bottles and Moebius strips?
All the problems alleged for EQUALP's descent into structures also apply
to EQUAL's descent into lists; it's only a matter of probabilities. Hence,
I don't believe this issue can be settled by technical discussion.
The only non-time-wasting effort I can see to do from now on is to look for
some way to present our dilemma to a broad "user" community. We could try
to tell them, in cursory terms and few words, of the technical arguments
that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them
decide (by straw vote?) if the extra functionality provided by this proposal
is worth the extra risk.
Related Issues:
-- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE,
READTABLE, STREAM, etc. pairwise disjoint?
-- Will CLOS require EQUAL to be "generic"? Also, what about COPY?
-- JonL --
∂09-Jun-88 2136 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:36:23 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:34:39 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88 21:27:54 PDT
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100426.AA26522@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT <880608-202925-3823@Xerox>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88 11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
-- JonL --
∂09-Jun-88 2307 X3J13-mailer Issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 23:07:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:05:43 PDT
Date: 9 Jun 88 23:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue status
To: x3j13@Sail.stanford.edu
Message-ID: <880609-230543-6121@Xerox>
For this meeting, I have been broadcasting those issues where either:
a) there has been convergence within the cleanup committee and the issue is
ready for voting by X3J13 or,
b) there has not been any mail in the cleanup committee on the issue for a
significant period of time, even when there have been additional significant
remarks.
I've tried to mark the issues in the latter status as DRAFT, the idea being that
you have some idea of what other significant issues remain before the cleanup
committee, and might have some comments or contributions that will guide our
deliberations. I hope you will understand that the issues for this meeting are
not as uniformly "baked" as our previous submissions.
There are a number of thorny issues that have been in committee for a long time
(some for well over a year); as time goes on, it becomes less useful to attempt
to postpone them to the "next" X3J13 meeting, especially given the schedule for
a draft standard.
I have a number of other issues to mail out; they will be followed by a list of
all of the issues mailed.
Thanks,
Larry
∂10-Jun-88 0056 X3J13-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 00:56:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:55:18 PDT
Date: 10 Jun 88 00:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
To: x3j13@SAIL.STANFORD.EDU
line-fold: no
cc: Masinter.pa@Xerox.COM
REPLY-TO: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880610-005518-6180@Xerox>
!
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
Category: ENHANCEMENT
Edit history: Version 1 by Pitman 03/01/87,
Version 2 by Pitman 03/09/87 (address potential numbers)
Version 3 by Masinter 23-May-88, revive
Version 4 by Masinter 10-Jun-88, fix nits
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are used as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed
specifically if only to say that they are still illegal. There
should be no ambiguity about what is legal and what is not.
An example of such a symbol is 68020A .
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
In the case of `potential numbers' (as per p341) in a feature
spec, say that they are allowed for use in this context. If the
implementation does not support the syntax in question, it is
permitted to treat the syntax as if it denoted a feature which
was known not to be present. That is, in any implementation where
a potential number which is denoted by a character sequence <X> can
be parsed by the reader as either a number or a symbol, then
#+<X> will skip the next form iff the expression
(MEMBER (LET ((*READ-BASE* 10.)
(*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "<X>"))
*FEATURES*)
yields false, without prejudice to decision about whether <X>
denotes a number or a symbol. If <X> cannot be read by the reader
because it is a potential number, then #+<X> will skip the next
form as if any feature <X> might have been intended to denote was
not present.
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Comparison is performed by EQL.
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Cost to implementors:
Changes to implementations not already supporting this feature
would probably be very minor.
Cost to Users:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Aesthetics:
No issues not already addressed above.
Discussion:
Pitman initiated this proposal and thinks that it would be a
worthwhile extension.
Steele asks about treatment of potential numbers, such as #+68020a .
Revision 2 of this proposal addresses that issue, by explicitly
stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since
some implementations support numbers here and since the purpose of
this feature is to allow selection of such implementations. He
wishes people would write Symbolics-3600 rather than 3600 since it
isn't clear that 3600 is meaningful in the abstract. He wants to
see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique
to numbers. Many feature names with only alphabetic characters
could be likewise criticized. In practice, brevity is important
because AND and OR will greatly increase horizontal size of
feature-spec expressions and often it's desirable to still have
enough room to the right to grind the conditionalized expression.
Dick Gabriel opposed this proposal: "unless there is a compelling
reason to do otherwise, it is best to have as few different rules and
concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such
that <object> is a symbol or a boolean expression. I don't see any gain in
expressive power if we extend this to include numbers, yet we've extended
the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon
some people will not know what I mean when I say I mailed this message
from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and
hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression
or a slip of the TIP for simply -3600."
∂10-Jun-88 0107 X3J13-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:07:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:59:37 PDT
Date: 10 Jun 88 00:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <880610-005937-6183@Xerox>
!
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
21-May-88, Version 2 by Pitman (correct test case, add discussion)
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special (for the purposes of either binding or reference).
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
This function will be useful in determining whether a reference to
the variable named by SYMBOL in the indicated ENVIRONMENT will be
a special reference.
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment. It is instead dependent only on the global
environment and on the declarations of the form which would accomplish
the binding. Whether the variable has been globally proclaimed special
can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
variable is locally declared SPECIAL can be checked only by parsing
the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Symbolics Genera has undocumented internal function which does this.
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally.
Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.
∂10-Jun-88 0108 X3J13-mailer Issue: STEP-ENVIRONMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:08:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:07:49 PDT
Date: 10 Jun 88 01:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: STEP-ENVIRONMENT (Version 1)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Line-fold: NO
Message-ID: <880610-010749-6191@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
An additional problem is that CLtL says that STEP is a macro. However,
it is unclear what portable expression the macro could expand into,
especially if STEP evaluates the form in the current environment. STEP
is really a variation of the Lisp interpreter, which makes it more like
a special form than like a macro.
The interaction of STEP with the compiler is not specified.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Change STEP from a macro to a special form.
3. Clarify that it is an error to compile a STEP form.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. STEP is really a variation of the Lisp interpreter, which makes it more
like a special form than like a macro.
3. As a debugging TOOL, STEP forms do not need to be compiled. It would
be difficult to specify precisely what should happen when a STEP form is
compiled (which parts of the form are to be executed interpretively), so
it's easier to duck the issue. Use "is an error" rather than "signals
an error" so that compile-only implementations are permitted to compile
STEP forms.
Current practice:
Symbolics Common Lisp behaves as proposed.
Cost to Implementors:
1 requires passing an environment around, which should be easy.
2 and 3 are just restrictions, so they should cost nothing.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
∂10-Jun-88 0154 X3J13-mailer Issues for discussion at June 1988 X3J13 meeting
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:54:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:53:53 PDT
Date: 10 Jun 88 01:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues for discussion at June 1988 X3J13 meeting
TO: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <880610-015353-6228@Xerox>
The following issues are for discussion at the X3J13 meeting. Except for
FUNCTION-TYPE-REST-LIST-ELEMENT and SETF-FUNCTION-VS-MACRO, you
should have received copies of these.
Issues already discussed at previous meetings:
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
Released before. not remailed to X3J13 for the June meeting.
* FUNCTION-TYPE (Version 10, 22-May-88)
(Change definition of FUNCTIONP, function type ...)
Rewritten for X3J13/June 1988
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
Released before. not remailed to X3J13 for the June meeting.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New issues for the June 1988 X3J13 meeting (some in DRAFT form):
* ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
* DATA-TYPES-HIERARCHY-UNDERSPECIFIED (Version 1, 24-Mar-88)
( STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE are
required to be disjoint from other types)
* DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
*** DRAFT ***
* DEFPACKAGE (Version 2, 23-Mar-88)
(Add new DEFPACKAGE macro to handle common package operations.)
*** DRAFT ***
* DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1, 13-May-88)
(two slots in a single DEFSTRUCT can't have the same name)
* DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1, 13-May-88)
(its OK to have zero slots)
* DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1, 13-May-88)
(clarify when initial value forms for defstruct options get evaled)
* EQUAL-STRUCTURE (Version 2, 8-Jun-88)
(What do EQUAL EQUALP and friends do on structures, vectors, etc.)
*** DRAFT: Multiple proposals ***
* EVAL-OTHER (Version 2, 8-Jun-88)
(Allow other data types to self-evaluate.)
* FUNCTION-CALL-EVALUATION-ORDER (Version 1, 22-Mar-88)
(when function cells are extracted isn't defined)
* HASH-TABLE-PRINTED-REPRESENTATION (Version 2, 8-Jun-88)
(make hash tables print as #H).
*** DRAFT ***
* LAST-N (version 2, 12-Mar-88)
(Extend LAST to take an optional N)
* MACRO-FUNCTION-ENVIRONMENT (Version 2, 8-Jun-88)
(Add environment argument to MACRO-FUNCTION)
* SHARPSIGN-PLUS-MINUS-NUMBER
(Allow #+68000, #-3600)
* SPECIAL-VARIABLE-TEST (Version 2, 21-May-88)
(Add SPECIAL-VARIABLE-P)
* STEP-ENVIRONMENT (Version 1)
(STEP isn't a macro, its a special form.)
* SUBSEQ-OUT-OF-BOUNDS (version 2, 29 Mar 88)
(it is an error to give out-of-bounds args to subseq)
* WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5, 7-Jun-88)
(interaction of WITH-OUTPUT-TO-STRING and FORMAT on adjustable arrays)
∂07-Jul-88 0732 X3J13-mailer DRAFT Minutes June meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Jul 88 07:32:06 PDT
Date: 7 Jul 1988 10:29-EDT
Sender: MATHIS@A.ISI.EDU
Subject: DRAFT Minutes June meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-88 10:29:46.MATHIS>
DRAFT
Minutes of the X3J13 Meeting, Boston, June 15, 16 1988.
Wednesday, June 15
09:00 am Item 1, 2, 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2. Introduction of attendees. Attendees list.
Future meetings. Bob recommended the Holiday Inn in Fairfax, VA for
October meeting which will be hosted by Contel.
Dick Gabriel described a planned Lisp conference for October
or November, 1989, in the Boston area. He also announced that, during
the conference, part of the Lisp museum will be on display.
Hawaii meeting will be Jan 17-20, 1989 (the week after POPL meets in
Austin, TX).
The Spring 1989 meeting will be held in the Palo Alto area.
Item 3. Approval of agenda.
Item 4. Approval of minutes. David Slater moved to table the approval
of the minutes until after JonL White and Larry Masinter's
comments were distributed.
9:30 am Item 5
Item 5 Editorial Subcommittee Report, Kathy Chapman.
Phase 1 document (1000p) will be ready for review in mid-July.
The document will be available for remote FTP access. Bob
Mathis emphasized that special document access needs should
be discussed with Bob or Kathy. The document is in TEX.
Phase 1 involves rewriting the CLTL into the format that
the X3J13 document will use. Review involves verifying the
correctness of the rewrite. The final document for Phase 4
is scheduled for June, 1989. Kathy is looking for volunteers
to suggest actual changes.
10:00 am Item 6
Character Subcommittee Report, Thom Linden
A proposal should be ready for voting on at the next meeting.
Bob Mathis noted that this topic was of great interest to many
different ISO committees and that this was the right time to
distribute our solution to the other committees.
10:05 am Item 7
Iteration Subcommittee Report, JonL White
Of the three proposals, Loop is ready for voting and OSS and
Generators need users. Guy Steele asked for a straw vote on
how many companies used some portion of Loops. Approximately
1/3 indicated that their companies did.
10:45 am Morning Break
11:10 am Item 7 (continued)
Dick Waters presented OSS, its description and status. The
files are available to FTP. Dick encouraged use and feedback.
The copyright on OSS belongs only to Dick, not to MIT. The
restriction on its use is that people will use it unchanged.
If changes are made, the name of the system should be changed.
Chris Perdue discussed the status of Generators. The
discussion focused on how complex proposals are to be included
in CL: ie., as kernel features, as features within a hierarchical
structure, or as optional features. No resolution occured.
12:30 pm Dick Waters raised some potential CL problems, and possible
solutions, in the area of prettyprinting, particularly.
12:35 pm Item 9, Lunch
01:45 pm Item 10
CLOS (88-002R, 88-003R), Gregor Kiczales
Gregor described the responses to comments on the last version of
CLOS, Chapters 1 and 2. Detailed questions were raised and
discussed.
03:00 pm Afternoon Break
03:15 pm Item 10 (continued)
Discussion continued on remaining issues to be resolved and
the form a resolution should make. Gregor moved and David
Moon seconded that:
The X3J13 Committee hereby votes to accept Chapters 1 and 2 of
the Common Lisp Object System, as defined in document 88-002R, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent substative and wording changes will be
handled with the usual editorial and cleanup process.
Jim Antonio (who?) moved and JonL seconded an amendment to strike
the second sentence. The motion was defeated 9-12.
Dick Gabriel moved, and Larry Masinter seconded, to change the
motion to the following:
The X3J13 Committee hereby accepts chapters 1 and 2
of the Common Lisp Object System, as defined in document
88-002R, for inclusion in the Common Lisp language being
specified by this committee. Subsequent changes will be handled
through the usual editorial and cleanup processes.
The motion passed 22-0.
The original motion, as amended, passed 24-1.
Guy Steele stated the appreciation of himself and the committee
for the work of the CLOS subcommittee.
04:55 pm Ending remarks
Bob Mathis encouraged people to join relevant subcommittees. Larry
Masinter gave an overview to the Cleanup status that will be the
topic of the agenda tomorrow.
05:05 pm Item 11 Meeting adjourned
Thursday, June 16
09:10 am Item 12
Item 12 Call to Order. Bob Mathis
Attendance at the ISO meeting at Sunbird is limited to people
appointed by the committee. The present attendees are planned
to be Bob Mathis, Dick Gabriel, Kathy Chapman, Patrick Dussud,
and one person from the Scheme standardization effort.
David Bartley discussed IEEE Scheme Standardization meeting. Will
Clinger and someone else (who?) will be co-chairs.
Macro Subcommittee
Members of the subcommittee will be contacted by Bob Mathis to
find out status and intentions.
CLOS Subcommittee
Dick Gabriel announced that chapters 1 and 2 will be published
in SIGPLAN Notices and Lisp Journal and made available in such a
way as to allow republication by any vendor.
Error Subcommittee
Kent Pittman distributed a document describing what would
happen if an error were signalled. Gregor moved, and
Dick Gabriel seconded, that:
The X3J13 committee hereby accepts revision 18 of the Common
Lisp Condition System, as defined in document 88-005, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent changes will be handled through the
usual editorial and cleanup processes. These changes will
include any necessary to reconcile the proposal with CLOS.
Bob Mathis called for a straw vote asking whether the second
sentence should be included in the motion. The straw vote
passed. Bob Mathis called for a straw vote asking whether
the third sentence should be included. The straw vote passed
13-11.
The motion was voted and passed unanimously. The committee
applauded Kent Pittman's work. Guy Steele moved, and JonL
White seconded, a vote of appreciation for Kent's efforts.
This motion also passed unanimously.
Compiler Cleanup Subcommittee
Sandra Loosemore discussed three proposals which had been
distributed yesterday. She encouraged comments to be sent
to the subcommittee by August 1st to:
CL-COMPILER@SAIL.STANFORD.EDU
Volunteers were asked to contact Sandra Loosemore or Steve
Haflich. Bob Mathis noted that the X3J13 committee was expecting
an overview of the issues and specific proposals to be
distributed in time to allow a vote at the October meeting.
Editorial Subcommittee
Kathy Chapman suggested that a member of each subcommittee
whose work is voted into CL should migrate first to the
Cleanup Subcommittee and then to the Editorial Subcommittee.
Kathy also suggested that each subcommittee should be
represented in the Editorial Subcommittee. There will be a
meeting of the Editorial Subcommittee during lunch.
10:40 am Morning Break
11:00 am Item 8
Item 8, Definition Specs Proposal, JonL White
JonL White repeated the Palo Alto proposal. The ensuing
discussion brought out the need for a written version of
the proposal that addresses implementation costs. It was
hoped that a written version would be available in advance
of the October meeting.
11:30 am Item 13
Item 13 Cleanup, Larry Masinter
Larry presented a status report showing that of the 21 issues
now under consideration, only three are still in "draft"
form. It is expected that a final vote will be taken in
October on currently known issues. The work after October
would then focus on ambiguities noted by the Editorial
Subcommittee and problems encountered with language areas
added to CL.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE-REST-LIST-ELEMENT be added to the language.
Jeff moved, and Beckerly seconded, that the function
will be tabled until the next meeting. The motion to table
passed.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE be added to the language.
12:30 pm Item 14 Lunch
01:20 pm Item 13 (continued)
Discussion centered on the automatic coercion of lambda
expressions. JonL White moved, and Gregor seconded, to
Change Section 2e
Clarify FUNCALL and APPLY and all CL functions that take
function arguments to also take a symbol, which will be
coerced to a function as with SYMBOL-FUNCTION.
Change Section 6b
(COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
Mike Beckerley moved, and JonL seconded, to amend the amendment
to eliminate the word "clarify" from 2e and to replace
"similar to" with "as if by".
02:30 pm Afternoon break
02:40 pm Item 13 (continued)
David Moon moved, and David Slater seconded, to amend the
motion on the floor to
Add Section 2f:
FUNCALL and APPLY and all CL functions that take function
arguments also take a list whose car is LAMBDA, which will
be coerced to a function as if by
(EVAL '(FUNCTION ,x))
The amended motion failed 9-13.
A move to call off debate was called. The motion failed 8-12.
Steve Haflich moved, and Chris Perdue seconded to
Add Section 2f:
This is an incompatible change, in that FUNCALL, APPLY, and
all CL functions that take function arguments are not
required to take a list beginning with LAMBDA.
Barry Margolin moved, and Steve Haflich seconded, a friendly
amendment to Steve's amendment to
Add Section 2f:
This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the function
The motion to amend the amendment passed 21-0.
The amendment to the cleanup proposal passed 20-1.
David Moon moved, and Barry Margolin seconded, to cut off
debate. The movement passed 17-4.
Jeff Dalton moved, and David Slater seconded, to table the
amended motion. The motion to table failed 6-13.
The chair announced that if 5 people believe the issue should
be sent to a mail ballot, it will be. No one challenged this
decision. Five people did not vote for a mail ballot.
The amended motion, FUNCTION-TYPE, passed 16-7.
Larry Masinter moved, and Guy Steele seconded, to add
SETF-FUNCTION-VS-MACRO to the language.
Following discussion and acquiring of a volunteer to help,
Larry Masinter moved to table the motion. The
tabling motion passed 15-6.
The discussion then moved on to the 18 new proposals.
Larry Masinter moved, and Sandra Loosemore seconded, to add
ADJUST-ARRAY-FILL-POINTER to the language. The motion passed
unanimously.
Larry Masinter moved, and xx seconded, to add
DATA-TYPES-HIERARCHY-UNDERSPECIFIED to the language.
Discussion noted that this is an incompatible change to
existing implementations, although the representatives of the
implementations felt this was a positive change.
Guy Steele moved, and Dan Pierson seconded, to change the
wording of the proposal as follows:
"explicitly forbid" to be replaced by "it is an error for"
The amendment passed unanimously.
The amended proposal passed unanimously.
Larry Masinter moved, and Dan Pierson seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME to the language. Discussion
on this was delayed.
Barry Margolin moved, and Steve Haflich seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER to the language. The
motion passed unanimously.
The motion to add DEFSTRUCT-SLOTS-CONSTRAINTS-NAME was tabled
by general consent.
The discussion of DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
The discussion of EVAL-OTHER led to no resolution of opinion
so it was decided not to bring the proposal to a motion.
The discussion of FUNCTION-CALL-EVALUATION-ORDER led to no
resolution so it was decided not to bring the proposal to a
motion.
Dan Pierson moved,and Barry Margolin seconded, to add LAST,
with an argument, to the language. The motion passed 16-3.
Larry Masinter moved, and Dan Pierson seconded, to add
MACRO-FUNCTION-ENVIRONMENT to the language. The motion passed
unanimously.
Larry Masinter moved, and Barry Margolin seconded, to add
SHARPSIGN-PLUS-MINUS-NUMBEr to the language. The motion
moved was the proposal with the phrase "list of symbols and/or
numbers" changed to "list of symbols and/or integers".
The motion failed 7-10.
The discussion of SPECIAL-VARIABLE-TEST led to no resolution
of opinion so it was decided not to bring the proposal to a
motion.
The discussion of STEP-ENVIRONMENT led to no resolution of
opinion so it was decided not to bring the proposal to a
motion.
Larry Masinter moved, and Dan Pierson seconded, to add
SUBSEQ-OUT-OF-BOUNDS to the language. The motion passed
unanimously.
The discussion of WITH-OUTPUT-TO-STRING-APPEND-STYLE led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
Larry brought up a list of issues which are currently under
discussion.
05:05 pm Closing Comments
Jim Allard will talk to Bob Mathis about starting a working group on
delivery issues.
Dan Pierson offered to work with Barry Margolin on a position
paper on how implementations have to deal with the standard.
Bob Mathis emphasized that the October meeting would be a wrapup
of many technical issues. January will be a joint meeting with
ISO. The Palo Alto meeting will be a review of full document so
that at the following meeting we have the goal of having a document
which can be made public.
05:20 pm Item 16 Adjournment
Minutes submitted by Mary S. Van Deusen (June 16, 1988)